Now on consistency:

For optional (“opt”) and a value T (“val”) the following holds:

– opt = val; -> opt == val
– opt.get() = val -> opt == val

So for optional this should also hold and it does for rebinding. Difference is that case 1 reassigns the reference and case 2 changes the object, but it is explicit in doing so.

Of course “foo = val” is ambiguous in the context where “foo” is of generic type (and possibly a reference).

But imagine “T” being a class and you want to call a method on it. You’d have to do: opt->foobar().

So “optional” is ALREADY behaving like a pointer –> Rebinding!

Note: I would also agree to make it explicit. Hence optional::operator=(U) is disallowed except when U is optional, null_opt, or reference_wrapper.

But I feel 1 case is forgotten in the discussion: opt1 = opt2. The expected behaviour for this is a change of the value of the optional -> Rebinding for references.

TLDR: An optional already feels like a pointer with defined ownership (namely: none). Hence rebinding.

Similar thoughts here. I would expect optional to be consistent with the following little wrapper W that looks like a int&:

struct W {
W(int& x) : ref(x) {}
W& operator=(int x) { ref = x; return *this; }
W& operator=(W x) { ref = x.ref; return *this; }
int& ref;
};

in this case we already have:

int i1 = 1;
int i2 = 2;
optional o1 = i1;
optional o2 = i2;
o2 = o1; // set i2 to 1
o2 = nullptr;
o2 = o1; // rebind o2 to i1
int i3 = 3;
o2 = i3; // set i1 to 3

so the behavior of optional::operator= is already dependent on emptiness, and thus I don’t see how a rebinding behavior for optional would bring any sort of consistency between optional ref and optionals in general.

My thoughts exactly. Based on the Single Resposibilty Princple, the job of optional is to add one more value to the range of types available, not to add new features (such as assigning to references). The job of making references rebindable is done by reference_wrapper. You can always combine the two: optional<reference_wrapper> and you have got rebinding behaviour with the null state:

using namespace std;
int i = 42;
int j = 27;
int k = -3;
optional<reference_wrapper> o1 = ref(i);
optional<reference_wrapper> o2 = ref(k);

o1 = ref(j); // o1 now references j. i, j and j themselves are unchanged
o1 = o2; // o1 now references k. i, j and k themselves are unchanged
o1->get() = 84; // updates k
o1 = nullopt; // o1 now references nothing at all.
o1->get() = -67; // Undefined behaviour – dereferencing a null optional

This behaves very much like a pointer without the arithmetic, albeit with different syntax, so we don’t need optional to do that for us.

So if we already can have rebinding behaviour, we should make it assign to the underlying, just as references themselves do. However, we have to ask ourselves what do we do if either the source or destination is null/unset? The solution is to disallow assignment except when the source is nullopt_t and force the caller to dereference of the optional (to a T&) to get assignment:

optional o3 = i;
optional o4 = k;

o3 = j; // doesn’t compile
o3 = o4; // also doesn’t compile
*o3 = j; // updates i so that i == j
o3 = nullopt; // this _is_ allowed and resets o3
*o3 = k; // Undefined behaviour – dereferencing a null optional

When talking about consistency, there’s also `std::reference_wrapper` to consider, which is also rebindable, but does not have a separate null state.

I guess it all depends on the use case. Do you want optional references to act like references that can be null (non-rebindable), or like pointers that have an explicit separate null state (rebindable)? There are use cases for both. Maybe that means there have to be two classes with distinct names that make clear what’s happening?