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;
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.
-- 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