In C++, we can declare an object (a variable) of type
T, and we can give this variable
an initial value (through an initializer.
(c.f. 8.5)). When a declaration includes a non-empty initializer (an initial
value is given), it is said that the object has been initialized. If the
declaration uses an empty initializer (no initial value is given), and neither
default nor value initialization applies, it is said that the object is
uninitialized. Its actual value exist but
has an indeterminate initial value (c.f. 8.5.9).
to formalize the notion of initialization (or lack of it) allowing a program
to test whether an object has been initialized and stating that access to
the value of an uninitialized object is undefined behavior. That is, when
a variable is declared as
and no initial value is given, the variable is formally
uninitialized. A formally uninitialized optional object has conceptually
no value at all and this situation can be tested at runtime. It is formally
undefined behavior to try to access the value of an
uninitialized optional. An uninitialized optional can be assigned a value,
in which case its initialization state changes to initialized. Furthermore,
given the formal treatment of initialization states in optional objects,
it is even possible to reset an optional to uninitialized.
In C++ there is no formal notion of uninitialized objects, which means that
objects always have an initial value even if indeterminate. As discussed
on the previous section, this has a drawback because you need additional
information to tell if an object has been effectively initialized. One of
the typical ways in which this has been historically dealt with is via a
npos, -1, etc... This is equivalent to
adding the special value to the set of possible values of a given type. This
super set of
T plus some
is some stateless POD-can be modeled in modern languages as a discriminated
union of T and nil_t. Discriminated unions are often called variants.
A variant has a current type, which in our case is either
Using the Boost.Variant
library, this model can be implemented in terms of
There is precedent for a discriminated union as a model for an optional value:
the Haskell Maybe
built-in type constructor. Thus, a discriminated union
serves as a conceptual foundation.
variant<T,nil_t> follows naturally from the traditional
idiom of extending the range of possible values adding an additional sentinel
value with the special meaning of Nothing. However,
this additional Nothing value is largely irrelevant
for our purpose since our goal is to formalize the notion of uninitialized
objects and, while a special extended value can be used to convey that meaning,
it is not strictly necessary in order to do so.
The observation made in the last paragraph about the irrelevant nature of
respect to purpose of
an alternative model: a container that either has a
T or nothing.
As of this writing I don't know of any precedence for a variable-size fixed-capacity (of 1) stack-based container model for optional values, yet I believe this is the consequence of the lack of practical implementations of such a container rather than an inherent shortcoming of the container model.
In any event, both the discriminated-union or the single-element container models serve as a conceptual ground for a class representing optional—i.e. possibly uninitialized—objects. For instance, these models show the exact semantics required for a wrapper of optional values:
T, it is modeling an initialized optional.
T, it is modeling an uninitialized optional.
Tmodels testing if the optional is initialized
Tfrom a variant when its current type is not
T, models the undefined behavior of trying to access the value of an uninitialized optional
T), it is modeling an initialized optional.
Tfrom an empty container models the undefined behavior of trying to access the value of an uninitialized optional
Objects of type
are intended to be used in places where objects of type
would but which might be uninitialized. Hence,
purpose is to formalize the additional possibly uninitialized state. From
the perspective of this role,
can have the same operational semantics of
plus the additional semantics corresponding to this special state. As such,
be thought of as a supertype of
Of course, we can't do that in C++, so we need to compose the desired semantics
using a different mechanism. Doing it the other way around, that is, making
is not only conceptually wrong but also impractical: it is not allowed to
derive from a non-class type, such as a built-in type.
We can draw from the purpose of
the required basic semantics:
Additional operations are useful, such as converting constructors and converting assignments, in-place construction and assignment, and safe value access via a pointer to the wrapped object or null.
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
T interface, the
following must be noted: Even if all the operations supported by an instance
T are 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
itself is merely 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 inexistent 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 inexistent) 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:
*p = 2 )
( 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 conversion to
bool to convey
the notion of optionality.
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 object
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 OptionalPointee 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
does not have shallow-copy so does not alias: two different optionals never
refer to the same value unless
itself is a reference (but may have equivalent values).
The difference between an
and a pointer must be kept in mind, particularly because the semantics of
relational operators are different: since
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