Re: [boost] New Library Proposal: dual_state

From: Fernando Cacciola (fernando_cacciola_at_[hidden])
Date: 2005-07-15 11:48:22

Hi Andrew,

It seems we all agree that *alternative* values for optional objects are
only needed at the point were such optionals are used, not constructed; so
we agree that it is not the direct responsability of optional<> or any other
such
utility to provide that.
Having said that, I do see how the kind of adapter you are proposing can be
used to deliver an alternative
value given a possibly empty container (the concept could be generalized to
operate on containers, not just
optional<>).
But I'm still largely unsure about the utility of such a thing because it
actually hides too much information, like
the alternative value which happens to be meaningfull in the local context
were it is needed.
That is, given:

void legacy_consumer( int n = -1 ) ;

optional<int> v = get_optional_value();

legacy_consumer( v ? *v : -1 ) ;
legacy_consumer( default(v) ) ;

The version with the ? is far _better_ IMO than the adapater version becuase
it makes it explicit what value is being pass if v is empty (and even that a
value is beging pass in such a case).
default(v) OTOH is as uninformative as it can be and so I don't think is any
better.

In one of your posts you mention that you intend the adapter to offer
clarity, yet, how can it do that
when it hides the default value? I would say that it is "terser", but
definitely not more clear.
If in the end it all boils down to

"value_exist ? value : default"

how is a "function object" instead of that a key advantage?

You said that

"the door has been flung open to many templated constructs that are more
difficlt with the ?: operator.  For example, a boost::transform_iterator
could be created with the adapter to automatically access the underlying
objects in a sequence."

I disagree.. can you post a concrete example with a construct that is indeed
more difficult with operator ?: (... and be fair; i.e. code the operator
version the right way...)

IMO you still need to show that the adpator is indeed a good thing;
if you do that we can start discussing a proper design and implementation
for it.

Best

Fernando Cacciola
SciSoft