On Mon, 2 Aug 2021 at 17:18, Jason McKesson via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> On Mon, Aug 2, 2021 at 6:26 AM Andrey Semashev via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
> >
> > On 8/2/21 12:28 PM, Lénárd Szolnoki via Std-Proposals wrote:
> > >
> > > The Achilles' heel of optional<T&> seems to be assignment. I'm of the
> > > opinion that it simply shouldn't have assignment from arguments of type
> > > T, but I believe there is no perfect answer.
> >
> > Personally, I have no problem with rebinding semantics of
> > optional<T&>::operator=(T&). That it would affect the referred object
> > makes no sense because (a) there may not be such an object (if the
> > optional is empty) and (b) no other version of optional<T> acts this
> > way.
>
> Um, yes they do. If you have an engaged `optional<T>`, and you assign
> a `T` to it, it assigns to the engaged value. It does not
> unengage/re-engage itself.
>
> So if you have this:
>
> ```
> optional<T> t = ...; //some T
> T& t_ref = *t;
> t = ...; //some other T
> ```
>
> If each of those pieces of code is valid, then `t_ref` is also valid.
> It still refers to the value you assigned to the `t`.
>
> The semantics you want for `optional<T&>` violate this. The `t_ref` in
> this case would refer to the old referenced object, not the new one.

That, to me, seems like an almost "of course" level reason for having
the assignment "assign through" if
an optional<T&> is engaged. If it's engaged, it invokes the assignment
of the held entity, and if that has reference
semantics, so be it.