FYI I'm currently working closely with Andrzej Krzemienski on a std proposal which, among other things, involves the long awaited update to the Boost implementation.
Could you give a use case for optional<T&>. When reading the doc about I completely understand the other use cases: * return types * parameters * locals * members * expensive unnecessary default construction
We could be having the same conversation about optional<bool>. Here the documentation is clear: it works as expected but is the user probably should be using tri-state.
We could optimize optional<bool> to store ~0 to indicate unset. I personally don't think it's worth doing that, since use case is questionable.
As far as I can tell optional<T&> is a type which can be easily confused with optional<T>, but is really equivalent to T*. It also allows for debates about the meaning of reassignment.
I'm not dead set against this optimization. I'm just wondering if anyone will really benefit and if it's worth adding a specialization + tests.
Speaking for myself, I do not have a need for optional reference. I have been using Boost.Optional for many years, I find it extremely useful; and I never had a use case for optional reference. On the other hand, others seem to be in need of optional references.Andrey said in this thread that that he wants to use it. The only two motivating use cases that triggered the addition of optional references (that I am aware of) is the interface of Boost.Variant (see http://lists.boost.org/Archives/boost/2003/02/44585.php) and the use case for Boost.Spirit (see http://lists.boost.org/Archives/boost/2003/10/55584.php). I would be reluctant to just discard these use cases. On the other hand, if they are allowed, the controversy of assignment arises. One thing to note is the requirement for optional references is not motivated by optimization opportunities, but additional behavior.
Side question: is streamablity going to be in your proposal? It is not currently. The reason for that is that there is no clear way how it should be implemented (a similar issue applies to pairs, tuples, variant, any, etc...) See http://lists.boost.org/Archives/boost/2005/03/81619.php for discussion. I believe that the problem is with the streaming itself. For instance, should streaming out and then streaming the result back in produce the same value? Some people expect that, but even std::string could not provide this behavior.
Regards, &rzej