Victor A. Wagner Jr. wrote:
At 20:28 2005-10-14, Joe Gottman wrote:
"Joel de Guzman" <joel@boost-consulting.com> wrote in message news:diphko$tba$1@sea.gmane.org...
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) 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.
Here is an interesting thought experiment. What should std::swap do with optional<X &>? In general, swap(x, y) usually has the same effect as the following code, except for perhaps a stronger exception guarantee and faster performance: Foo temp(x); // Step 1. Assume x and y are of type Foo x = y; // Step 2 y = temp; // Step 3
That being the case, what would the following code do? int a = 1; int b = 2; optional<int &> x(a); optional<int &> y(b); swap(x, y);
Assume that swap is not specialized for optional, and consider two cases. Case 1: rebind. Step 1 of swap above binds temp to a, step 2 rebinds x to b and step 3 rebinds y to a. Thus the end result is that x and y are each rebound to what the other one was pointing to before.
Case 2: no rebind. In this case, Step 1 above binds temp to a as before. But step 2 results in *x = *y, so a is set equal to b and both a and b now equal 2. Then step 3 results in *y = *temp, so b is set equal to a, but since a and b are already equal due to step 1, there results in no change. Thus the end result is that the original value in a is lost.
Of course we would specialize swap for optional<T> to call swap(*x, *y) if both x and y are initialized, but I think the fact that this is not equivalent to the unspecialized version is an argument in favor of the rebind semantics.
I concur that it's an argument in favor of rebind.
Of course not! Have you read my follow up on tuples doing the same? Do you mean that tuple<T&> should also have a rebind semantics because it's not swapping correctly? Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net