Re: [boost] New Library Proposal: dual_state

From: Eelis van der Weegen (gmane_at_[hidden])
Date: 2005-07-10 08:47:18

Jost, Andrew wrote:
> *THE UNDEFINED_OBJECT*
> A third difference between Boost.optional and dual_state involves the
> very personal issue of syntax.  It is nonsense to tell people to prefer
> one syntax over another, but I will note that dual_state's use of the
> undefined_object lends a unique feel to code that uses it.  The
> programmer's intent is unmistakably clear when "undef" is used to
> initialize members:
> 
> [snip]
> 
> The concept of using self-evident constructs to obviate documentation is
> a valuable one.  It is detailed in the Boost.noncopyable notes.

Boost.Optional has some interaction with (including initialization from) 
boost::none, which seems to correspond to your "undef".

Regarding guaranteed object delivery:
I must say I find this design aim questionable. The whole point of these 
facilities (Boost.Optional and your dual_state) is that there are situations 
where it is simply not possible to assign a meaningful value to the object. It 
is only logical that this implies that wherever the object is used, there must 
either be some invariant in user code that guarantees that it is defined, or an 
if/else to deal with both cases. Quickly default constructing the underlying 
object when it turns out that the user is attempting to use it when it is not 
defined seems like a very arbitrary thing to do, and I believe it will only be 
sensible and correct in very few situations. This is the first reason why the 
notion of Boost.Optional being a model of OptionalPointee appeals to me.

Regarding full operator support:
I'm very skeptic about this design aim, mainly because it is an attempt at 
making the class as a whole a transparent wrapper around the underlying object, 
which is fundamentally not possible in C++ and will only cause confusion. Sure, 
the syntax is nice for a few cases, but conceptually it makes the interface 
complex and inconsistent. This is the second reason why the notion of 
Boost.Optional being a model of OptionalPointee appeals to me: the syntax and 
semantics are pretty much as one would expect (from a smart pointer).

So, in conclusion, the motivation for your dual_state is very valid, but 
personally I think Boost.Optional is a more appropriate design.

Eelis