Boost logo

Boost :

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 (
>>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
> 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

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at