Re: [boost] New Library Proposal: dual_state

From: David Abrahams (dave_at_[hidden])
Date: 2005-07-10 08:59:27

"Jost, Andrew" <Andrew_Jost_at_[hidden]> writes:

>>From: boost-bounces_at_[hidden]
> [mailto:boost-bounces_at_[hidden]] On Behalf Of Eelis van der Weegen
>
>>Jost, Andrew wrote:
>>> I am curious if there is support for what I'm calling a "dual_state"
>>> template class.
>> From your description it sounds a lot like Boost.Optional. What are
> the main differences?
>>Eelis
>
> I'll admit I did not even pause at Boost.optional when I scanned the
> library listing for previous work, a failure in my ability to connect
> the description, "Discriminated-union wrapper for optional values," with
> the concept I had in mind.  

Oh, you're right!  That is a terrible one-line description, because

  a. It uses technical terms that many people probably don't know
     "discriminated union"

  b. optional doesn't really act like a union (in any way that matches
     my intuition)!  I understand the theoretical connection, of
     course, but nobody is thinking that way when they read brief
     descriptions.

<snip>

> I see three important differences.
>
>
> *GUARANTEED OBJECT DELIVERY*
> First and foremost, dual_state is guaranteed to always deliver a valid
> object (or reference), even if this object (or reference) must be
> conjured from nowhere.  

Interesting.  Sounds like dual_state should be built on top of optional.

> *FULL OPERATOR SUPPORT*
> A second difference is that dual_state directly supports the full
> complement of operators (for built-in types), 

That sounds a bit like Alexander Nasonov's dynamic_any.

> this due to the fact that most operators are delegated through the
> implicit conversion-to-base-type operator.

Oh, that's less interesting, but still useful.  Expect a debate over
whether the implicit conversion is a good idea, though.

> *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:
>
>
> // -- begin
> using dual_state_namespace::constants::undef;
>
> class bar { ... };
> class foo {
> public:
>     dual_state<int> x, y, z;
>     dual_state<bar> a;
>
>     foo() : a(undef), x(undef), y(undef), z(undef) {}
> };
> // -- end
>
>
> The concept of using self-evident constructs to obviate documentation is
> a valuable one.  It is detailed in the Boost.noncopyable notes.

Nice idea.  It's good to have something like that available, at least.
Asking whether it should be required makes it, as you say, a very
personal issue.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com