Re: [boost] Report from Mont Tremblant C++ Committee meeting

From: Joel de Guzman (joel_at_[hidden])
Date: 2005-10-16 03:26:52

David Abrahams wrote:
> Joel de Guzman <joel_at_[hidden]> writes:
> 
> 
>>David Abrahams wrote:
>>
>>>Joel de Guzman <joel_at_[hidden]> writes:
>>>
>>>I *really* don't have an opinion about what the right choice should
>>>be.  That said, terms like gobbledegook seem needlessly judgemental,
>>>and as such I think they only cloud the issues.
>>
>>But, IMO, it *is* unclear and wordy jargon (http://tinyurl.com/954xg)
>>I find the explanation very difficult to follow. 
> 
> 
> I know what "gobbledegook" means; it's highly pejorative.  A link to
> the explanation in question would be more useful here.

I know that you know what that means. I do not mean to
belittle anyone. If that's the case, then I apologize.

>>Of course you need an assignment operator... and structs do
>>provide a guide: The point is that you can't rebind it. 
> 
> 
> You sure can, using nasty tricks.  You just destroy the struct in
> place and re-construct it with the new reference binding.

Ah yes, you can do anything in C++.

>>You can do anything with it, and in the common case, just assign the
>>rhs to the lhs
> 
> 
> It's non-obvious to me that it's the common case.  Reference members
> are odd beasts, rarely used in my experience, and I am not sure
> there's a "usual treatment" for assignment that makes sense.  I will
> agree that the nasty tricks are rarely used and usually best avoided.
> However, we have at least one example where that was agreed to be best
> (read the short thread at
> http://lists.boost.org/Archives/boost/2002/12/41278.php) and of course
> we have at least one example where rebindability was shown to be the
> most useful behavior: reference_wrapper itself.

Agreed. After thinking about it for some while, it seems I am being
swayed by the reference_wrapper model. If you see my other post
regarding the swapability of optional<T&> and tuple<T&>, I seem
to be showings signs of concession. I might, on one condition:

Allow rebinding *ONLY* on assignment from another optional<T&>.

     int a = 1;
     int b = 2;
     optional<int&> x(a);
     optional<int&> y(b);
     x = y; // rebind
     y = a; // no rebind! assign a to b

This BTW is the exact semantics of reference_wrapper. Replace
optional<T&> with reference_wrapper<T> and you'll get the same
behavior.

That said, I still am unsure because this will ultimately open a
can of worms for the behavior of tuple<T&> and variant<T&, nil>.
Howard Hinnant hinted at a proposal to simply fix swap for
tuple. Maybe that's all that's needed.

This might be my last post on this issue. Please understand that
I mean no offense to anyone. Please understand too that my
primary concern is inter-library consistency. As one who have
spent quite a bit of time on tuple development, and spent quite
a bit of time on using optional references too, and hope to use
all three (tuple, optional, variant), I care for consistency in
their behavior. If you decide to fix one, then the others should
be fixed. I do not buy the argument that optional is different
because of its nullability property. In the recent thought
experiments, we never touched on null optionals in any way.

Sincerely Yours,
-- 
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net