In C++, we can declare an object (a variable) of type
T, and we can give this
variable an initial value (through an initializer.
(cf. 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 (cf. 8.5/11).
intends 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
optional<T> 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
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 special value:
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
plus some nil_t—where
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
boost::variant<T,nil_t>. 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 the additional
with respect to purpose of
suggests an alternative model: a container that either
has a value of
T or nothing.
As of this writing I don't know of any precedent 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