On Mon, 2 Aug 2021 at 17:35, Barry Revzin <barry.revzin_at_[hidden]> wrote:

>> That, to me, seems like an almost "of course" level reason for having
>> the assignment "assign through" if
>> an optional<T&> is engaged. If it's engaged, it invokes the assignment
>> of the held entity, and if that has reference
>> semantics, so be it.
>
>
> Except it's the wrong semantic, which is why precisely zero implementations of optional that support references (and there are several) do this. And it's the wrong semantic because it has wildly different behavior based on initial state, and thus basically has no meaningful semantic behavior that you can rely on. Something something standardizing a wealth of existing practice.

What makes it the wrong semantic? I can easily describe what it does.
How do you describe what optional<T>::operator= does when
it invokes the assignment of T when T is not a reference, but doesn't
invoke it otherwise? By describing it with just those words, perhaps?
:)
I don't immediately see why that's a better semantic; it seems to
introduce exactly the vectorbool problem where assignment of an
optional sometimes assigns and sometimes constructs, *even for the
same state of the optional*.

> The right semantic is the assignment does actually do "unengage/re-engage" and the right way to think about it is that optional already does this. Except that since for many types, assignment can be much more efficient then destroy/construct, we defer to the assignment operator. It's just that for references, we know that this is wrong, so we can avoid doing it.

I don't quite grok the "optional already does this" part. For any T,
optional's assignment doesn't change which T object an optional holds
if you assign to an engaged optional.