Boost logo

Boost :

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

Victor A. Wagner Jr. wrote:
> At 20:28 2005-10-14, Joe Gottman wrote:
>>"Joel de Guzman" <joel_at_[hidden]> wrote in message
>>>David Abrahams wrote:
>>>>Joel de Guzman <joel_at_[hidden]> 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
>> 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?


Joel de Guzman

Boost list run by bdawes at, gregod at, cpdaniel at, john at