Brock Peabody wrote:
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Joel de Guzman
FWIW, a tuple<T&> can't be re-bound.
True, but neither can a tuple<T&> be null.
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.
IIUC the proposed changes do not prevent rebinding:
int i = 1, j = 2;
boost::optional<int&> oa = i;
oa = j; //i is 2
oa.reset();
oa = j; //oa is rebound
Hmmm. I smell something wrong with that.
If you want rebinding semantics, use a pointer
But optionals are so much cleaner. Given a T& your only options would be a naked pointer which would have to be unpleasantly documented or to put it in a shared pointer with a noop deleter.
Agreed.
, or use boost::ref.
I guess boost::optional<boost::ref<T> > would do the trick.
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.
Maybe the right solution then is that boost::optional<T&> can only be initialized via constructor.
Yes. This is what I expected. As always, when in doubt, do as the <place your primitive here>. In this case, tuple got it right: no special case handling for references. The behavior, WRT assignment and construction, should follow that of a struct with a T& member.
There are really two separate issues:
1) should optional<T&> be rebindable
I think it's handy to be able to rebind optional<T&> but then again, I don't see why we can't rebind regular references either other than a lack of good syntax for doing it.
On the other hand, I can see that since T& isn't rebindable, making optional<T&> rebindable causes problems in generic code and I can always use optional<ref<T> > anyway.
Exactly!
2) should optional<T&>::op= forward to its reference when bound.
I still think this is a bad idea. For one thing, you can't disallow rebinding as long as you've got an op= unless you make op= sugar for *oa =, in which case assigning to unbound optional<T&> is undefined.
When in doubt, do as the references do. I strongly believe that tuple, optional and variant should all have the same behavior when it comes to dealing with references. Tuple did it right. I hope optional and variant follow. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net