Re: [boost] Formal review: Optional library

From: William E. Kempf (wekempf_at_[hidden])
Date: 2002-12-11 16:45:09

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.

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.

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.

William E. Kempf