Re: [boost] New Library Proposal: dual_state

From: Fernando Cacciola (fernando_cacciola_at_[hidden])
Date: 2005-07-11 12:11:10

Hi Andrew,

> [SNIP]
>
> *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.  This is in direct contrast to Boost.optional,
> which maintains that
>
Well, it never ocurred to me to let optional<> provide default values.
I just can't think right now of any situation were I would use it.
Can you post some *real life* examples?
(the example you posted is not good enough because as it is
one would argue wthat the optional/dual_state wrapper is not
needed to begin with)

As David Abraham said, however, IF it turned out to be useful
(I can't see it right now) it seems that such an
"optional with default" could be a specialized form of optional<>.

Off the top of my head, a default value could be supported in
at least 3 ways:

(1) Storing an actual default value in each optional instance.

(2) Parametrizing optional<> with a static factory that can be
called to provide such defauts.

(3) Using T's default constructor (if any) to create such a value.

Notice that optional<> does not require T to be DefaultConstructible.

Another thing to consider is were exactly do default values appear;
and how are the semantics defined in this case.

> A programmer may view dual_state's "guaranteed delivery" behavior as
> either advantage or liability, but his opinion, if tenable, must focus
> on the relative benefits afforded by guaranteed objects versus the risks
> posed by -- one might say -- "junk" default values.
> I would say it depends on the application.
> re to the point, if the answer to what
> goes "<== HERE" is always "set len = 0" for a particular application,
> then dual_state could offer greater clarity with less work.
>
The problem I see in your design is that the "benefit" of having
a default optional value can only exist at the consumption point
(becasue the code producing an uninitialized optional does not
have a default value, otherwise it wouldn't be uninitialized);
But *there*, what is a meaningful default value and whether
is important for the design to be explicit about the
fact that the value being consumed is not the one produced
is a local problem.
An optional<>/dual_state<> is an object constructed by
a producer that does not know what a good default is
(if it knew, if wouldn't construct uninitialized values), so is
unclear how could the class/instance by itself could provide such
local information (the default value beneficial at the
consumtion point).

As David Abraham mentioned, optional<> instances are similar
to default parameters, and notice how there the
default value is specified at the consumtion point, not the
production point.
IOWs, the following:

void foo ( int age = -1 ) ;

foo(35);
foo();

reads:

The function foo() uses an age, but if you don't have one,
don't worry, just don't specify it. foo() will take care
itself of a reasonable default value.

Now the analogy for optional<> would go something like this:

optional<int> get_age();

optional<int> age = get_age();
*** do something with age here **

IMO, get_age() cannot and would not return any default
value, if it could, then it should have a return type
of just 'int'; or at most, return an initialized value.
So it is up to the consumer code to deal with the
possible empty age.
But how? That really depens on the consumer code.
I can choose to deal only with real ages,
so my code would start like: if ( age )
Or I might decide that -1, or perhaps 0, are good
fallback values...
But in any event, these decisions are local
to the consumer code, so I can't picture how
to encode such decisions in optional<> itself.

Well, others have already commented on the rest of your post
so I won't repeat that here :-)

Best regards,

Fernando Cacciola
SciSoft