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

From: Joel de Guzman (joel_at_[hidden])
Date: 2005-10-15 19:27:03

David Abrahams wrote:
> Joel de Guzman <joel_at_[hidden]> writes:
> 
>>I think this is again an artifact of the confusion between the
>>dual interfaces that optional provides. optional has an identity
>>crisis of being a pointer (as the author's original model) and
>>a variant<T, nil> (which I suggested later on). The rebinding
>>behavior that Fernando rationalized was long and winding and
>>confusing. I don't recall anymore his exact rationale. All I
>>know is that when you have to explain your design using so much
>>wordings, then something is wrong, and I don't buy the gobbledegook.
> 
> 
> 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 don't agree that
I am being judgemental. IMO, it's important for a model to be
as simple as possible. If a certain aspect of a library cannot be
explained in clear and concise manner, then that will potentially
lead to misinterpretations, loopholes and gotchas later on.

>>There *is* an alternative design which is a lot simpler and I've
>>been saying that again and again: do as the structs do. 
> 
> 
> 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
can do anything with it, and in the common case, just assign the
rhs to the lhs, 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.
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.

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