David Abrahams wrote:
Joel de Guzman <joel@boost-consulting.com> writes:
David Abrahams wrote:
Joel de Guzman <joel@boost-consulting.com> 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