Joel de Guzman <joel@boost-consulting.com> writes:
David Abrahams wrote:
"Brock Peabody" <brock.peabody@npcinternational.com> writes:
it improves my ability to make code self-documenting. Personally, I like it the way it is. I've used optional quite a bit and it makes sense to me that operator= changes what an optional holds. I don't think it is a good idea to give operator= special semantics for references. I had the same feeling. That's what I meant when I said "It depends on whether you view optional<T> as a T that might just happen to be missing, or as a container for a T." I think "a container for a T" is a more manageable meaning for optional<T>.
FWIW, a tuple<T&> can't be re-bound.
Correct. It's all a question of what we want optional to be.
I'll state my point again. I noticed this odd behavior of optional some years ago: giving optional re-binding semantics *is actually* giving it special semantics and requires special case handling. This leads to subtle problems like the one Fernando is experiencing now. If you want rebinding semantics, use a pointer, or use boost::ref. The right behavior, I strongly believe, is to do as the references do. This is what tuple did and we have nary a problem with it.
Okay. -- Dave Abrahams Boost Consulting www.boost-consulting.com