
Joel de Guzman wrote:
David Abrahams wrote:
Joel de Guzman <joel@boost-consulting.com> 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 wonder what explanation you are referring to? You still haven't addressed the very issue that forms the core of that explanation.
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.
And I totally agree.. But if a design causes misinterpretations, loopholes and gotchas later on, then it might look like being as simple as possible while in reality is over-simplified. Without rebinding semantics, that is, over-simplifying the problem, assignment can do 2 totally different things. That's a source for misinterpretations, loopholes and gotchas.
[SNIP]
Of course you need an assignment operator... and structs do provide a guide: The point is that you can't rebind it.
Yes you can.. you meant you shouldn't.
You can do anything with it, and in the common case, just assign the rhs to the lhs,
What if thre is no rhs to assign to??
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.
That is a sensible behaviour when embeeding a reference that never references nothing. If your model supports nullability, that is, the reference can reference nothing, then _consistent_ rebinding is a reasonable choice. Best -- Fernando Cacciola SciSoft http://fcacciola.50webs.com/