RE: [boost] Formal review: Optional library

From: Iain K.Hanson (iain.hanson_at_[hidden])
Date: 2002-12-12 05:14:46

> [mailto:boost-bounces_at_[hidden]]On Behalf Of William E. Kempf
> Sent: 11 December 2002 20:42
>

[ snip ...]

>
> I agree with this.  The optional<> concept takes some type and extends
> it's possible values to include a new "uninitialized" value.  It seems
> wholly logical to me for this:
>
> optional<int> a();
> optional<int> b();
> optional<int> c(1);
> optional<int> d(2);
> optional<int> e(2);
>
> assert(a == b);  // both uninitialized
> assert(a != c);  // one uninitialized
> assert(c != d);  // both initialized to different values
> assert(d == 3);  // both initialized to same value

I don't agree with this. It seems to be mixing both pointer and value
semantics.

assert( a == b ) // pointer semantics.
if this used value semantics then this would mostly fail and randomly
suceeed.

given that we can already do *c != *d then if relationl operators are to
add any value, they would need to be:

assert(a == b);  // both uninitialized
assert(a != c);  // one uninitialized
assert(c == d);  // both initialized

>
> However, not all types wrapped in optional<T> will be
> comparable... so,
> I'm not adverse to leaving comparison operators out just to
> simplify the
> interface.  I just don't agree with the current rationale.

If that is the compromise that is required, I can live with it.
but it would be nice to have them as I have defined above as
we already have the value operators and it would be a short hand
for:

 get( c ) == get ( d )
or
 c.get( ) == d.get( )

/ikh