On Mon, Aug 2, 2021 at 10:56 AM Ville Voutilainen via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> On Mon, 2 Aug 2021 at 17:46, Ville Voutilainen
> <ville.voutilainen_at_[hidden]> wrote:
> >
> > On Mon, 2 Aug 2021 at 17:35, Barry Revzin <barry.revzin_at_[hidden]> wrote:
> >
> > >> 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.
> > >
> > >
> > > Except it's the wrong semantic, which is why precisely zero implementations of optional that support references (and there are several) do this. And it's the wrong semantic because it has wildly different behavior based on initial state, and thus basically has no meaningful semantic behavior that you can rely on. Something something standardizing a wealth of existing practice.
> >
> > What makes it the wrong semantic? I can easily describe what it does.
> > How do you describe what optional<T>::operator= does when
> > it invokes the assignment of T when T is not a reference, but doesn't
> > invoke it otherwise? By describing it with just those words, perhaps?
> > :)
> > I don't immediately see why that's a better semantic; it seems to
> > introduce exactly the vectorbool problem where assignment of an
> > optional sometimes assigns and sometimes constructs, *even for the
> > same state of the optional*.
>
> Ha, okay, after digging up some explanation of this by Matt Calabrese,
> the problem is that generic code
> written to work with either an optional<T> or optional<T&> will fail
> miserably unless the assignment of optional<T&> rebinds.
> Okay then.

The example code I wrote could easily be generic code, where you get a
reference to the thing in the `optional<T>`. It won't work in the
presence of a rebinding assignment operator.