FJoel de Guzman wrote:
David Abrahams wrote:
Joel de Guzman <joel@boost-consulting.com> writes:
Rebinding semantics are there _precisely_ and _only_ to solve a problem posed by nullability.
Sorry, I don't buy that.
Why not?
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)
FWIW, I never said nor proposed it as a pointer. That was something that people just wronly assumed and keep asumming. All I said, and which I'll keep saying, is that both pointers and optional<> can represent absent objects. But that's not because optional<> is a pointer, is becasue both optional<> and pointer's are somehing else: OptionalPointees.
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 can clearly see that you don't recall my rationale. For some reason you just keep failing to see the reasons I have for the rebinding. (the rebinding is built on purpose, for a reason, and not as a side consequence of some design or implementation, so in reality you shouldn't say you don't buy my reasons when I am just stating them)
[SNIP] Keep it as simple as possible. variant<T&, nil> does the right thing. I don't understand why optional can't.
I can see that... So let me explain it once again: If optional<> had NO rebinding. That is, if optional<> were to simply agreegate a reference as you propose, the following would happen: optional<int&> or ; int v = 3 ; int w = 5 ; int x = 10 ; int& rv = v ; int& rw = w ; int& rx = x ; or = rv ; // 'v' is bound for the first time here. or = rw ; // 'or' is initialized so 'v' is changed to 5 [1] or = none ; // back to absent // unlike [1], 'or' is bound now to 'x' rather than 'v' changing its value or = rx ; As you can see, WITHOU REBINDING, in one case of assignment, the value of the referenced object changes, but in the other case of assignment, another object is referenced. I consider this a problem and so I propose rebinding as a way out. Now, anyone reading please understand this: It is the existence of the incosistency above THE ONLY REASON for the rebinding proposal. That incosistency would not exist if it were not because of the nullability of optional<>. Or to avoid a confusion rooted on an undefined term, because of the fact that the lhs can be absent or not, and that affects the semantics of the assignment. Any argument against rebinding _must_ address that problem specifically simply because it is that specific problem alone the reasons for rebinding.
Perhaps it's because of the dual pointer interface.
It has nothing to do with interfaces.
[SNIP] "Pointers can be null or dereference-able, Optionals can be null or dereferenceable, therefore Optionals are models of Pointers". It seems that Fernando's rationale follows along the lines "Pointers can be null or dereference-able, Optionals can be null or dereferenceable,
Pointers can be rebound, therefore Optionals should be rebound-able."
I don't recall anyone saying that last sentence. But in any case, I would disagree with that just as you do. But again, the need for rebinding has nothing to do with pointers. -- Fernando Cacciola SciSoft http://fcacciola.50webs.com/