Re: [boost] Re: Re: Re: Re: Optional, tie, and iterator_adaptor
Andrei Alexandrescu [EMAIL PROTECTED] wrote: By the way, could optionalT use variantT, SomeInsipidType as a backend? I suggested that before. Now I think that it is not practical. It can, but it will not be optimal. I see it the other way now. I suggest that a partial specialization of variantT, empty be written that takes advantage of optionalT in its implementation. I think now that the partial specialization of variantT, empty will satisfy the anti-pointer-like crowd. variant seems to have the right interface. Perhaps we were barking up the wrong tree? Cheers, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: Re: Optional, tie, and iterator_adaptor
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 {
optionalT 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
Re: [boost] Re: Re: Re: Re: Optional, tie, and iterator_adaptor
Fernando Cacciola [EMAIL PROTECTED] wrote: Point taken. There's no need to argue anymore. I guess significantly more feedback will weight the balance. Thanks for all your comments! It might look the other way around but they were very helpful. Bottom line is, and most importantly, optional gets the job done and it does it really well! :-) FWIW, it's easy to write a wrapper around optional that satisfies our wishes (in fact, I sent a class interface scheme to Dave G. tell me if you are interested). It might also be a nice idea to write a partial-specialization of variantT, empty that takes advantage of the optimizations of optional. Best Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
