From: Fernando Cacciola (fernando_cacciola_at_[hidden])
Date: 2002-12-11 17:43:31
----- Original Message -----
From: "William E. Kempf" <wekempf_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.
> 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.
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
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.
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk