Since the purpose of optional is to allow us to use objects with a formal
uninitialized additional state, the interface could try to follow the interface
of the underlying
as much as possible. In order to choose the proper degree of adoption of
the following must be noted: Even if all the operations supported by an
instance of type
defined for the entire range of values for such a type, an
extends such a set of values with a new value for which most (otherwise
valid) operations are not defined in terms of
optional<T> itself is merely a
wrapper (modeling a
any attempt to define such operations upon uninitialized optionals will
be totally artificial w.r.t.
This library chooses an interface which follows from
interface only for those operations which are well defined (w.r.t the type
T) even if any of the operands
are uninitialized. These operations include: construction, copy-construction,
assignment, swap and relational operations.
For the value access operations, which are undefined (w.r.t the type
T) when the operand is uninitialized,
a different interface is chosen (which will be explained next).
Also, the presence of the possibly uninitialized state requires additional
operations not provided by
itself which are supported by a special interface.
A relevant feature of a pointer is that it can have a null pointer value. This is a special value which is used to indicate that the pointer is not referring to any object at all. In other words, null pointer values convey the notion of nonexistent objects.
This meaning of the null pointer value allowed pointers to became a de facto standard for handling optional objects because all you have to do to refer to a value which you don't really have is to use a null pointer value of the appropriate type. Pointers have been used for decades—from the days of C APIs to modern C++ libraries—to refer to optional (that is, possibly nonexistent) objects; particularly as optional arguments to a function, but also quite often as optional data members.
The possible presence of a null pointer value makes the operations that
access the pointee's value possibly undefined, therefore, expressions which
use dereference and access operators, such as:
= 2 ) and
p->foo() ), implicitly convey the notion of optionality,
and this information is tied to the syntax of the
expressions. That is, the presence of operators
-> tell by themselves
—without any additional context— that the expression will be undefined
unless the implied pointee actually exist.
Such a de facto idiom for referring to optional objects
can be formalized in the form of a concept: the
OptionalPointee concept. This
concept captures the syntactic usage of operators
-> and contextual conversion
bool to convey the notion
However, pointers are good to refer to optional objects, but not particularly good to handle the optional objects in all other respects, such as initializing or moving/copying them. The problem resides in the shallow-copy of pointer semantics: if you need to effectively move or copy the object, pointers alone are not enough. The problem is that copies of pointers do not imply copies of pointees. For example, as was discussed in the motivation, pointers alone cannot be used to return optional objects from a function because the object must move outside from the function and into the caller's context.
A solution to the shallow-copy problem that is often used is to resort
to dynamic allocation and use a smart pointer to automatically handle the
details of this. For example, if a function is to optionally return an
X, it can use
as the return value. However, this requires dynamic allocation of
is a built-in or small POD, this technique is very poor in terms of required
resources. Optional objects are essentially values so it is very convenient
to be able to use automatic storage and deep-copy semantics to manipulate
optional values just as we do with ordinary values. Pointers do not have
this semantics, so are inappropriate for the initialization and transport
of optional values, yet are quite convenient for handling the access to
the possible undefined value because of the idiomatic aid present in the
concept incarnated by pointers.
For value access operations
optional<> uses operators
-> to lexically warn
about the possibly uninitialized state appealing to the familiar pointer
semantics w.r.t. to null pointers.
However, it is particularly important to note that
optional<> does not have shallow-copy so does
not alias: two different optionals never refer to the same
T itself is
a reference (but may have equivalent values). The
difference between an
optional<T> and a pointer must be kept in mind,
particularly because the semantics of relational operators are different:
is a value-wrapper, relational operators are deep: they compare optional
values; but relational operators for pointers are shallow: they do not
compare pointee values. As a result, you might be able to replace
on some situations but not always. Specifically, on generic code written
for both, you cannot use relational operators directly, and must use the