Re: [boost] New Library Proposal: dual_state

From: Jost, Andrew (Andrew_Jost_at_[hidden])
Date: 2005-07-10 20:20:04

 > -----Original Message-----
> From: boost-bounces_at_[hidden] 
> [mailto:boost-bounces_at_[hidden]] On Behalf Of Eelis van 
> der Weegen
> Sent: Sunday, July 10, 2005 9:47 PM
> To: boost_at_[hidden]
> Subject: Re: [boost] New Library Proposal: dual_state
> 
> 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".

Good point, but I would also like to see overloaded == and != operators
using boost::none.

> 
> 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.

Our opinions differ on this point.  I believe there are cases where
providing a default object is quite appropriate, but again, it all
depends on the application.  If, as you say, an "invariant in user code"
can be used to control a program's behavior, why can't the defined and
documented behavior of default object delivery serve as the invariant --
especially if it simplifies syntax?  

> 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.

I'm skeptical, too.  I am happy to discard this idea.

> 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

Thanks, for your opinion.  I would say we mostly agree, except that I
believe there are cases where guaranteed object delivery is useful.
Perhaps something like dual_state would be best built as an addition to
Boost.optional, as David Abrahams has suggested.  So we could say
Boost.optional is a robust and appropriate design, and dual_state may
offer some useful (though, uh, optional) additions to Boost.optional.
Thanks again.

-Andy