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

From: David Abrahams (dave_at_[hidden])
Date: 2005-10-15 20:21:16

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 guess you're assuming optional<T&> maps onto a struct with a T&
>> member?  That model is not 100% obvious to me.  The only way to
>> initialize a plain struct with a reference member is using an
>> initializer list, and the assignment operator for such a struct can't
>> be used.
>
> [...]
>
>> So "the structs" in this case are never that simple, and they don't
>> provide a guide for what to do with optional<T&>, since the assigment
>> behavior for reference members is always explicitly decided by some
>> class designer.
>
> 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.

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

Your use case (details unknown to me) seems to speak for the other
choice.  Recently I brought an issue to the core working group
regarding the resolution of DR 103: should when T is int&, should 

   T const& 

be 

   int const& 

or simply 

   int&

?  Looking at how real use cases for the reference-collapsing rule
shake out was an important part of deciding the treatment.  So I think
it's worth surveying more use cases.

> but you cannot rebind it. 

> That is why I often switch between the "tuple" model, the "variant"
> model and the "struct" model. Both follow the struct model. And, by
> the struct model, what I am referring to is the limits on what you
> can do.

Then shouldn't we prevent assignment altogether?  If you are willing
to allow a user-defined assignment operator, it can do anything.

> Sure you need to have an assignment to a struct to give it sensible
> semantics. But you can't rebind. That IMO, is the sensible behavior
> when you are embedding/holding a reference.
>
>> I'd really like to see a careful and non-judgemental comparison of the
>> two possible design choices, describing the advantages and
>> disadvantages of each one.  Until we see something like that, I doubt
>> we will be able to come to a useful consensus.
>
> Ok. Agreed.

So who will prepare that comparison?

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com