"Dave Gomboc" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > [...] > 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 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost