Re: [boost] Formal review: Optional library

From: Fernando Cacciola (fernando_cacciola_at_[hidden])
Date: 2002-12-11 16:50:43

----- Original Message -----
From: "Peter Dimov" <pdimov_at_[hidden]>
To: "Boost mailing list" <boost_at_[hidden]>
Sent: Wednesday, December 11, 2002 5:47 PM
Subject: Re: [boost] Formal review: Optional library

> From: "Fernando Cacciola" <fernando_cacciola_at_[hidden]>
> [...]
> > (1) deep-constantness:
> >
> > I Followed David Abraham's suggestion and decoupled
> > constantness of the optional<> object with that of
> > the value being wrapped.
> > This is how pointers and most smart pointers work, so
> > the pointer semantic should suffice to explain this behaviour.
>
> Hm. Did Dave really suggest that? :-)
>
Sort of.
He said that if optional<> is supposed to offer pointer semantics
then it should not provide deep constantness simply because pointers
don't do that.

> To reiterate, my opinion is that deep constness is much more appropriate
for
> optional<>. Constness and copying go hand in hand: deep copy corresponds
to
> deep constness, and shallow copy corresponds to shallow constness.
> Optional<> does a deep copy. Even smart pointers that do deep copy use
deep
> const.
>
Good point.

Let me check if I followed your logic:

optional<T> opt(v) does a 'copy' of the 'v'; it does not hold onto the
'v' itself as if it were given a handle. So it clearly has deep copy
semantics.
Your argument is that since it has deep copy semantics, it should have
deep-constantness
too, right?

>
> > template<class T>
> > class optional
> > {
>
> [...]
>
> >     void swap ( optional& rhs ) ;
>
> Doesn't the standard std::swap do the job, by the way?
>
With the current implementation, yes, it does.
But if optional<> is eventually changed to use an implementation
with stronger exception guarantees, wouldn't it require a member swap()?
That's the reason I put it there.

> [...]
>
> > } ;
> >
> > template<class T> inline T* get ( optional<T> const& opt ) ;
>
> Why the free function?
>
On the user code I **really** prefer to write: get(opt) instead of opt.get()
becasue I like to decouple from class types as much as possible.
Perhaps this could be called get_pointer() as shared_ptr<> does.

> >
> > template<class T> inline void swap ( optional<T>& x, optional<T>& y ) ;
>
> [...]
> > This is utterly important now that is has safe_bool,
> > because IMO, Tanton Gibbs interpretation is correct;
> > given safe_bool:
> >
> > optional<int> opt0 ;
> > optional<int> opt1 ;
> >
> > (opt0 == 0 ) // true
> > (opt1 == 0 ) // true
> >
> > therefore....
> >
> > (opt0 == opt1) HAS TO BE TRUE.
> >
> >
> > If the comparison above is properly understood,
> > that is, if it is clear that the initialized states
> > are being compared and not the values, then there is
> > no problem, but considering that:
> >
> > optional<int> opt0(1);
> > optional<int> opt1(2);
> > (opt0 == opt1) // true
> >
> > is also true even though the values are different,
> > I think that allowing direct comparions will
> > create unneccesary confusion.
>
> I think that the comparisons we were discussing as a possible candidate
> required both the initialized states and the held values to match.
>
> This is consistent with the "optional as a container of zero/one" and the
> "optional as a value with an additional unitialized state" models.
>
I don't follow 'exactly'
Can you elaborate?

Fernando Cacciola