Re: [boost] Formal review: Optional library

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

----- Original Message -----
From: "William E. Kempf" <wekempf_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Wednesday, December 11, 2002 6:45 PM
Subject: Re: [boost] Formal review: Optional library

> David Abrahams said:
> > "Peter Dimov" <pdimov_at_[hidden]> writes:
> >
> >> 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? :-)
> >
> > Not exactly.  I said that deep constness is inconsistent with a
> > pointer-oriented interface.
> >
> >> 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.
> >
> > Oh, well yeah.  There are some smart pointers that do that.  I've
> > never touched one.  So maybe a "deep" optional with a smart pointer
> > interface is not such an odd beast.
>
> I'd have to agree with the analysis and would lobby for deep const as
> well, after this rationale.
>
OK.

> To my mind that leaves two things left undecided (by me, not necessarily
> by the group at large).  One is whether or not to include comparison
> operators.  I guess I'm currently undecided and would like to hear some
> rationale for both sides.
>
OK.
We can discuss this further.
Notice that Tanton considered relation operators to mimic pointers, meaning
that (opt1==opt2) should not compare values as if it were (*opt1 == *opt2);
even if both are initialized.
In the case of optional<>, however, there is not really a notion of 'pointer
value'; being the 'initialization state' the closest concept.
But I shown that if relation operators were to compare only initialization
states they would still be wrong.

So, I have a new argument against directing comparing optional<>:

even if comparison against one uninitialized value could be defined as a
definitive false, such
a comparison, with a syntax: (opt1==opt2), comparing values ( just as if it
were (*opt1==*opt2))
breaks pointer semantics.

> The other is the templated constructor from other optionals.  I still
> think this is important, but not as currently specified.  The current
> conversion only from const versions is not so important since we'll have
> "deep const".  But conversion from other types, such as optional<int> to
> optional<long> would be more complex than it should be with out this.  An
> implicit constructor would obviously be bad here, but an explicit one
> should probably be included.
>
Interesting point.
Being explicit it won't be dangerous, and it might be useful indeed.
I think I'll add it.

BTW: I've noticed after thinking about Peter's argument about
deep-copy/deep-constantness that, indeed,
due to the deep-copy semantics, optional<T const> cannot really be properly
supported, since, for instance,
reset( T const& ) cannot be provided.
Therefore, I think optional<T const> should not be supported; and
deep-constantness used instead.

Fernando Cacciola