On Wed, Nov 22, 2023 at 11:25 AM Barry Revzin <barry.revzin_at_[hidden]>
wrote:

>
>
> 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.
>

I mean my version isn't used enough in my codebase to make conclusions from
it. That's why I never mention it much.

How often does optional<T&> come up for you, how often is it outside of
templates, and how often does assignment in particular come up.


>
>
>> 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 goal isn't to save a single character. Doubt I've ever suggested that.

When we first standardized optional, I asked what the model was. Was it "a
T with an extra value"? Was it "a container of 1"? etc (there were a few
more choices)

Mostly the answer was "T with extra value". Maybe that was wrong from the
beginning. But no one wanted to think about it all the way through.


References aren't value types. I'm not sure why optional should magically
make them value types.



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

-- 
Be seeing you,
Tony