Joel de Guzman wrote:
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.
Interesting point!
Very!! This is another problem caused by non-rebinding semantics. Which of course, being a con of non-rebinding, turns into an argument in favor of rebinding.
Now consider this:
int a = 1; int b = 2; tuple<int&> x(a); tuple<int&> y(b); swap(x, y);
What happens after the swap? The same thing happens!
Yet, does tuple have to change and assume a rebinding behavior as optional did? Definitely not!
Why definitely not!?
(Aside: Keep in mind that we never touched on the nullability of optionals. There's no nulled optional at all anywhere in this thought experiment).
Which only means that I have now yet _another_ reason for the rebinding semantics.
At most, I might be inclined to think that boost::reference_wrapper does the right swap and rebind behavior (**):
[SNIP]
(**) reference_wrapper rebinds only on explicit copy construction and assignment from another reference_wrapper. Never from assignment from a T (its embedded type).
(***) Because it doesn't support direct assignment from a T. The cloest match to what optional<> has is: *opt=value which does not rebind, just as reference_wrapper() Best -- Fernando Cacciola SciSoft http://fcacciola.50webs.com/