On Mon, 20 Nov 2023 at 18:25, JeanHeyd Meneide via Std-Proposals <
std-proposals_at_[hidden]> wrote:

>
>
> On Mon, Nov 20, 2023 at 1:11 PM Marcin Jaczewski via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>>
>> I heard couple problems with the design of this optional,
>> as there are two competing approaches to how it should work.
>>
>
No, there were two hypothetical approaches, but there was no competition
because one of them was only hypothetical and one was real.


> Question is why then does the standard avoid some of this problems
>> and have for example `optional_ref<T>`?
>>
>
That has no advantages, it just avoids making a choice about the correct
behaviour.


> What you heard of is a fantasy scenario, cooked up by people who
> never implemented the optional they talked about. They spent so much time
> pontificating about it rather than trying it out and seeing the obvious
> flaws in its design that they rolled back clearly deployed, widely
> implemented, and heavily used existing practice for the standard version of
> std::optional. optional_ref<T> is a solution looking for a problem that
> never existed both in its theory beyond shallow FUD examples, and in its
> practice since it was literally never implemented.
>
> Ever.
>
> Paper: https://thephd.dev/_vendor/future_cxx/papers/d1683.html
> Blog: https://thephd.dev/to-bind-and-loose-a-reference-optional
>

And the new proposal we have for std::optional<T&> (which is also the only
proposal we currently have for it) chooses the sensible semantics for
assignment:
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2988r0.html