----- Original Message ----- From: "William E. Kempf" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, December 11, 2002 6:45 PM Subject: Re: [boost] Formal review: Optional library
> David Abrahams said: > > "Peter Dimov" <[EMAIL PROTECTED]> writes: > > > >> From: "Fernando Cacciola" <[EMAIL PROTECTED]> > >> [...] > >>> (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 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
