Re: [boost] Formal review: Optional library

From: Fernando Cacciola (fernando_cacciola_at_[hidden])
Date: 2002-12-12 15:01:44

----- Original Message -----
From: "David Abrahams" <dave_at_[hidden]>
To: "Boost mailing list" <boost_at_[hidden]>
Sent: Thursday, December 12, 2002 3:45 PM
Subject: Re: [boost] Formal review: Optional library

> >
> > In order to achieve this, I considered fundamental the following
> > rule of thumb:
> > If optional<> is replaced by a pointer, and provided that uninitialized
> > optionals are defined as null pointers, any exression using optionals
> > should either fail to compile or behave exactly the same.
> > This rule allows the programmer to unambiguously infer the
> > semantic of a given expression using optional.
>
> Have you got even a single real use-case where an optional can be
> usefully substituted for a pointer in generic code?
>
> I think it's important to have a few of these in hand before
> predicating interface design principles on the idea.
>
Fair enough.

I have not exactly replaced it in a completely generic code (a templated
algorithm),
but I had

(A)
replaced optional<T> by shared_ptr<T> many times:
this happens when the optional object grows too much for the deep-copy of
optional<>.
In this case, I switch to shared_ptr<> with dynamic allocation.
The recievers of the optional objects never had to change beyond the type of
the variables used.

(B)
replaced optional<T> as function arguments with pointers.
At some point I realized that the code inside the function would actually
behave
exactly the same even if the argument were pointers instead of optional<>.
Then I deprecated optional<> as arguments to functions because they were
unnecesary; but the point is that I never had to worry about the semantics
inside the function.

I concede that the above 'design principle' is more a desire than an
achieved goal,
but it is a useful one, IMO.
If you change from optional<> to pointers, the lower the impact the better.
Maybe the proposed interface doesn't give you this much, but clearly,
allowing relop
to compare values without the explicit dereference would spoil any chance of
fulfilling
this principle.

As it is currently specified, changes would have to be made on the
value-semantics (container-like)
part of the interface.
relational operators will appear on boolean contexts just like safe_bool, so
you would
have expressions testing for initialization states: ( opt == 0 ), and
expressions
testing for value equality: ( opt1 == opt2 ) both with the same syntax.

Fernando Cacciola