"Peter Dimov" <[EMAIL PROTECTED]> wrote in message 00d901c2d820$bd2225c0$1d00a8c0@pdimov2">news:00d901c2d820$bd2225c0$1d00a8c0@pdimov2... > David Abrahams wrote: > > "Peter Dimov" <[EMAIL PROTECTED]> writes: > > > >> 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 > > > > Really? You can't convert to an optional<T&>? > > You said "optional<T>" above. > > It may be possible to use optional<T&> (is it supported?)
No, it isn't. And I don't think it ever will. optional<X> intends to represent a value of type X wich is possiblly uninitialized. But you can't have X=T& since you can't have an uninitialized reference. Of course, optional<T&> could have a special meaning, but I can't see what would it be. What's the meaning of an optional reference? I think there cannot be such a thing. > or optional< > reference_wrapper<T> > but this looks like an "obfuscated C++" entry to me > compared to T*. What's wrong with it? What does optional<T&> add? > Exactly. An optional reference is almost like a possibly null pointer, except that references must be bounded. If given a particular design you would need optional<T&>, then you definitely need T* instead. -- Fernando Cacciola _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
