|  | Home | Libraries | People | FAQ | More | 
          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).
          optional<T>
          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
          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 special value: EOF,
          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 nil_t—where nil_t
          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 T or nil_t.
          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 T+nil_t
          serves as a conceptual foundation.
        
          A 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 nil_t
          with respect to purpose of optional<T>
          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:
Discriminated-union:
T,
              it is modeling an initialized optional.
            T,
              it is modeling an uninitialized optional.
            T
              models testing if the optional is initialized
            T
              from a variant when its current type is not T,
              models the undefined behavior of trying to access the value of an uninitialized
              optional
            Single-element container:
T), it is modeling an initialized
              optional.
            T
              from an empty container models the undefined behavior of trying to
              access the value of an uninitialized optional