From: Joel de Guzman (joel_at_[hidden])
Date: 2005-03-05 19:09:31
Brock Peabody wrote:
>>From: boost-bounces_at_[hidden] [mailto:boost-bounces_at_[hidden]]
>>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 = 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.
>>, 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.
> 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.
-- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk