śr., 22 lis 2023 o 20:13 Barry Revzin via Std-Proposals
<std-proposals_at_[hidden]> napisał(a):
>
>
>
> On Wed, Nov 22, 2023, 12:30 PM 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. Optional references-to-objects are not
>> assign-through.
>>
>> And that's supposed to make sense.
>
>
> Where you're going wrong is thinking of optional assignment as assign-through. The point of optional's assignment is to change the state of the optional. If you think about it as that - as optional's assignment - then everything does make perfect sense.
>
> It's only when you think about optional assignment as the specific syntax chosen as an optimization, and consider that syntax as the semantics, that things get confusing.
>
> Here's a long read:
> https://brevzin.github.io/c++/2022/05/24/optional-assignment/
>

Probably the most important part of this post is that
`std::optional<std::tuple<T&>>` can have the same problems as
`std::optional<T&>`.
Your version of "destroy + copy-construct" for `=` probably is best
for the long run.


> Barry
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals