On Wed, Nov 22, 2023, 9:03 AM Tony V E via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> I have implemented it.
>
> It just isn't used that much. So no real implementation experience either
> way. It hasn't been a problem, but neither optional<T&> nor assignment
> come up that much at all, so inconclusive.
>


Disagree. optional<T&> comes up quite a bit. And we use it a lot. I don't
understand where the claim comes from - it's clearly used.


> If anything, I'd say
>
> Imagine that vector.front() returns an optional<T&>...
>
> As the developer writing vector, I'd like assignment to rebind.
> As the developer using vector.front(), I'd like assignment to not rebind.
>
> auto f = vector.front();
> if (f)
> f = 17; // current optional would not be able to assign from an rvalue
>
> But again, totally inconclusive.
>

Disagree again. If you want to assign through, there's syntax for that: *f
= 17. This is the same thing you would write if front() returned a T*
instead. It's the most reasonable choice too - if you want to operate in
the T&, you pull out the T& and operate on that. Same as you would for any
other type. optional<T&> is an optional, so it behaves like an optional -
it's not literally a reference.

Muddling the semantics of assignment to save a single character of syntax
in this case doesn't seem like a great tradeoff.


> The underlying problem is references, not optional, but I'm not going to
> argue it.
>




>
> On Mon, Nov 20, 2023 at 1:25 PM 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.
>>> Question is why then does the standard avoid some of this problems
>>> and have for example `optional_ref<T>`?
>>>
>>
>> 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
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
>
>
> --
> Be seeing you,
> Tony
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>