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/

Barry

>