On Fri, 7 Feb 2020 at 11:36, Corentin <corentin.jabot_at_[hidden]> wrote:
>> On Fri, 7 Feb 2020 at 11:19, Corentin via Lib-Ext
>> <lib-ext_at_[hidden]> wrote:
>> > And these difference would not need to exist if std::optional had sane assignment semantics to begin with, which it unfortunately doesn't.
>>
>> What would the sane assignment semantics be? When have they been
>> communicated to LEWG and to the authors
>> of std::experimental::optional/std::optional?
>
>
> It was long before my time.
> In general I thing that when the committee can't agree on a good default, it is a sign there is no god default to be found, and it in this case, it is better
> to remove the operation entirely, as we did for equality on span.

I'm not sure I follow. If you're talking about "good default" that
would cover optional<T&> as well, the question
never really came up because reference types were punted out of
optional's allowed template arguments
from the very beginning. Thus we had no particular trouble agreeing on
the semantics of optional's assignments,
although those were heavily modified by various library issues from
the initial version that was in LFTS.

> In the case of optional, people would have had to either use
> opt = optional{my_value};
> *opt = my_value;
> Which makes the intent explicit and avoid the cognitive overhead of trying to remember what decision the committee took.

So you're talking about the presence of the converting assignments, or
assignments from T? Well.. I can certainly
say that the converting assignments were a significant burden and a
complexity increase for wordsmiths, implementers
and users alike, and they still are for proposals like P2047R0, An
allocator-aware optional type. And perhaps
for assignment-like operations, it would just be better to use named
functions that give more hints about what those
assignment-like operations do, as opposed to having to remember what
operator= does for which inputs.
But that is probably water under the bridge.