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 <codeclass="computeroutput"><spanclass="identifier">optional</span><spanclass="special"><</span><spanclass="identifier">T</span><spanclass="special">></span></code> and no initial value is given, the
variable is <spanclass="emphasis"><em>formally</em></span> uninitialized. A formally uninitialized
optional object has conceptually no value at all and this situation can
be tested at runtime. It is formally <spanclass="emphasis"><em>undefined behavior</em></span>
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: <codeclass="computeroutput"><spanclass="identifier">EOF</span></code>,
<codeclass="computeroutput"><spanclass="identifier">npos</span></code>, -1, etc... This is
equivalent to adding the special value to the set of possible values of
a given type. This super set of <codeclass="computeroutput"><spanclass="identifier">T</span></code>
plus some <spanclass="emphasis"><em>nil_t</em></span>—where <codeclass="computeroutput"><spanclass="identifier">nil_t</span></code>
is some stateless POD—can be modeled in modern languages as a <spanclass="bold"><strong>discriminated union</strong></span> of T and nil_t. Discriminated
unions are often called <spanclass="emphasis"><em>variants</em></span>. A variant has a
<spanclass="emphasis"><em>current type</em></span>, which in our case is either <codeclass="computeroutput"><spanclass="identifier">T</span></code> or <codeclass="computeroutput"><spanclass="identifier">nil_t</span></code>.
Using the <ahref="../../../../../variant/index.html"target="_top">Boost.Variant</a>
library, this model can be implemented in terms of <codeclass="computeroutput"><spanclass="identifier">boost</span><spanclass="special">::</span><spanclass="identifier">variant</span><spanclass="special"><</span><spanclass="identifier">T</span><spanclass="special">,</span><spanclass="identifier">nil_t</span><spanclass="special">></span></code>. There is precedent for a discriminated
union as a model for an optional value: the <ahref="http://www.haskell.org/"target="_top">Haskell</a>
<spanclass="bold"><strong>Maybe</strong></span> built-in type constructor. Thus,
a discriminated union <codeclass="computeroutput"><spanclass="identifier">T</span><spanclass="special">+</span><spanclass="identifier">nil_t</span></code>
serves as a conceptual foundation.
</p>
<p>
A <codeclass="computeroutput"><spanclass="identifier">variant</span><spanclass="special"><</span><spanclass="identifier">T</span><spanclass="special">,</span><spanclass="identifier">nil_t</span><spanclass="special">></span></code> follows naturally from the traditional
idiom of extending the range of possible values adding an additional sentinel
value with the special meaning of <spanclass="emphasis"><em>Nothing</em></span>. However,
this additional <spanclass="emphasis"><em>Nothing</em></span> 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.
</p>
<p>
The observation made in the last paragraph about the irrelevant nature
of the additional <codeclass="computeroutput"><spanclass="identifier">nil_t</span></code>
with respect to <spanclass="underline">purpose</span> of <codeclass="computeroutput"><spanclass="identifier">optional</span><spanclass="special"><</span><spanclass="identifier">T</span><spanclass="special">></span></code>
suggests an alternative model: a <spanclass="emphasis"><em>container</em></span> that either
has a value of <codeclass="computeroutput"><spanclass="identifier">T</span></code> or nothing.
</p>
<p>
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.
</p>
<p>
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
<spanclass="emphasis"><em>exact</em></span> semantics required for a wrapper of optional
between containers compare container size and if match, contained value
</li>
<liclass="listitem">
If the container is not empty (contains an object of type <codeclass="computeroutput"><spanclass="identifier">T</span></code>), it is modeling an <spanclass="emphasis"><em>initialized</em></span>
optional.
</li>
<liclass="listitem">
If the container is empty, it is modeling an <spanclass="emphasis"><em>uninitialized</em></span>
optional.
</li>
<liclass="listitem">
Testing if the container is empty models testing if the optional is
initialized
</li>
<liclass="listitem">
Trying to extract a <codeclass="computeroutput"><spanclass="identifier">T</span></code>
from an empty container models the undefined behavior of trying to
