On Mon, 2 Aug 2021 at 18:02, Jason McKesson via Std-Proposals
<std-proposals_at_[hidden]> wrote:

> > Ha, okay, after digging up some explanation of this by Matt Calabrese,
> > the problem is that generic code
> > written to work with either an optional<T> or optional<T&> will fail
> > miserably unless the assignment of optional<T&> rebinds.
> > Okay then.
>
> The example code I wrote could easily be generic code, where you get a
> reference to the thing in the `optional<T>`. It won't work in the
> presence of a rebinding assignment operator.

Right, we ostensibly have two different things here:

1) an optional_a<T> type that acts like a T as far as possible
2) an optional_b<T> type that imposes value semantics onto T

I don't think either of those things has fundamentally more "right
semantics" than the other. The proponents
of the latter certainly have examples where it's fundamentally
important to have those semantics, but it's equally
plausible to have code that fundamentally depends on the semantics of
the former.

Curiously enough, std::optional is in quite many ways in camp (1), yet
there's vehement insistence that it should
fall in camp (2) for assignment. I find some of the arguments for that
dubious, because they're claiming that there's
some fundamental correctness in that, and I don't believe there is, it
just happens to work for the cases these people write.

What's really unfortunate is that the standard doesn't provide a
barebones building block for easily writing either 1 or 2,
and it likely needs to standardize just one of them, leaving the users
who need the other out in the cold. If the building
block were provided, it would certainly be colder in the other camp
than the one that has their favorite higher-level package
standardized,
but it wouldn't be so freezing.