"Peter Dimov" <[EMAIL PROTECTED]> wrote in message 004501c2d819$9e067300$1d00a8c0@pdimov2">news:004501c2d819$9e067300$1d00a8c0@pdimov2... > Joel de Guzman wrote: > > David Abrahams wrote: > > > >> BTW, I just realized that a conversion from variant<T> to optional<T> > >> could be used to do extraction as well. Maybe it would be better to > >> ditch extract altogether and just use optional? > > > > I think this makes sense. The disadvantage is the overhead of optional > > just to do "extract"ion. > > That means an extra copy and inability to change that data held in the > variant using non-const extract. If we really need to go that route, it's > probably better to just make extract return a value. > Indeed. optional<T> IS a value (but 'optional') IOWs, the reason why you couldn't use optional<T&> for extract is not only because of the reference-to-reference problem but essentially conceptual: An instance of optional<T> contains a {copy-of} a 'value' of type T. In this case, the value would be the reference itself instead of the T object within the variant. If extract would return by-value (which it could), then optional<T> would make perfect sense (overhead aside); but AFAICT, exract is intended to access the object within, thus the T&/T* proposed flavours.
... I've been down this road before, you know: but I'll use the name 'peek()' for this operation. -- Fernando Cacciola _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
