-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Fernando Cacciola
...
I think "a container for a T" is a more manageable meaning for optional<T>.
Yet I need to weight the balance one way and I choosen to favor the wrapper view... much of the latest evolution goes in this way.
...
Well, I agree that optional<> is intended to give you something you don't get straight from the language, but as it is now, its goal is to offer you something more of an extension of what you already get than a replacement.
Furthermore, you can get rebinding semantics via optional< ref<T> >.
Hi Fernando, I don't know if you saw the rest of the discussion but I think that the consensus was that rebinding should be disabled on optional<T&> as you suggest, and along with it operator=. Optional<T&> would then only be initialized via constructor (like T& itself), and optional<T&>::operator= would be a compile time error rather than deferred to T::operator=. Does this seem right to you? Brock