On 22 November 2023 18:30:12 GMT, Jason McKesson via Std-Proposals <std-proposals_at_[hidden]> wrote:
>On Wed, Nov 22, 2023 at 11:25 AM Barry Revzin via Std-Proposals
><std-proposals_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.
>>
>>>
>>> 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.
>
>So what you're saying is that this is fine:
>
>```
>T t = value;
>t = other_value; //Assign-through to the object named by `t`.
>
>optional<T> t = value;
>t = other_value; //Assign-through to the `T` in `t`.
>
>T &t = object;
>t = other_value; //Assign through to the object referenced by `t`.
>
>optional<T&> t = object;
>t = other_value; //Not assign-through.
>```
>
>This is one of the few places in the language where a language
>reference is treated as a distinct concept from the object it is
>referencing. References to objects are assign-through. Optional
>objects are assign-through.

No, it is "initialise or assign", and it's mostly OK for value types where the two has the same semantics, but you can still get surprises if they are subtly different, like PMR containers and no allocator propagation on copy assign.

"initialise or assign" for a reference is "bind or assign through", which would probably be the worst of all options.

> Optional references-to-objects are not
>assign-through.
>
>And that's supposed to make sense.
>--
>Std-Proposals mailing list
>Std-Proposals_at_[hidden]
>https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals