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

Reply via email to