On Mon, Sep 01, 2003 at 09:22:01PM -0600, Dave Gomboc wrote: > [Fernando Cacciola] > > I'm saying that the choice made by variant<> in this regards is to the > > code using get<> as hopeless as undefined behaviour. I don't think that > > preconditions (and exceptions thereof) should be used to arbitrarily > > make the illusion of giving meaning to an operation that is undefined at > > the conceptual level. > > For myself, and I think also for Joel, "nil" is a fully legitimate value, > not a hopeless, meaningless, conceptually undefined value. It's quite > clear that you don't share this view. The conceptual divide here is > surprisingly large. > > I'm surprised to find myself suggesting this, but perhaps instead of > debating this issue further I and like-interested people should create and > submit a high-quality implementation of nilable.hpp to Boost. If > accepted, people could then choose whichever best meets their > needs/expectations.
I think this is a good idea too. Personally, I side with Fernando's conception of 'optional', but clearly there are two groups which each want a different (though similar) class. My contribution with this message is to mention that, rather than having two completely separate implementations, one could be built atop the other (or both from a common root). My hunch is that your "nilable" idea could easily be built as a very thin wrapper around "optional" (provided optional has a wide enough interface, but I think it does). Something along the lines of template <class T> class nilable { optional<T> o; public: T& get() { if( o ) return *o; throw "oops"; } // etc. }; -- -Brian McNamara ([EMAIL PROTECTED]) _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost