[boost] Re: (corrected) review of optional library

From: David B. Held (dheld_at_[hidden])
Date: 2002-12-12 23:11:46

"Dave Gomboc" <dave_at_[hidden]> wrote in message
news:Pine.LNX.4.44.0212121913240.30800-100000_at_boyne.cs.ualberta.ca...
> [...]
> In my opinion, optional<T> [which perhaps ought to be may_be<T>
> or maybe<T>, as an earlier poster suggested, also see below] works
> best as denoting a type T', whose assignable values are the legal values
> for type T unioned with the value "nil", or "nothing" (as in Haskell).
(It
> shouldn't be called "uninitialized", because that would be misleading.
> "nil" is a perfectly valid value for a variable of type T' to take.)

But isn't this different from what optional offers?  Isn't it true that the
uninitialized value that T can take cannot be named, like nil?  Or should
we simply create a special nil object that is uninitialized?

> Because "nil" is just another value, operator== can be defined
> straightforwardly.  If both are "nil", return true; if exactly one is,
> return false; otherwise the normal comparison value is returned.
>
> operator< could be left undefined, but it is simple enough to
> arbitrarily choose that "nil" is strictly less than every other value.  I
> don't see a downside to this, and it would ensure that T' is a strict
> weak ordering whenever T is, which is useful for STL usage.

Or, you could do as VB does, and have nil propagate right out of
the operators (but then they don't return bool).  Of course, that brings
up the question of whether they *ought* to return bool, or merely
ought to return something convertible to bool.

> [...]
> One could possibly provide a test for the nil state by declaring an
> enum (in some scope) that defined some (arbitrary) value to "nil", then
> providing an operator== that allowed comparisons on that enum type,
> to allow code such as:
> [...]

I think it would be better to construct a special templated nil type, along
the lines of Meyers' Null object (if that's possible).

Dave