On Sun, Jun 9, 2024 at 5:15 PM Lorenz Quack via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> Hi,
>
> On Sun, 2024-06-09 at 21:18 +0200, Giuseppe D'Angelo via Std-Proposals wrote:
> > Hello,
> >
> > On 09/06/2024 14:44, Lorenz Quack via Std-Proposals wrote:
> > > 1. Allow passing pointer-to-member (both data and function member) to std::optional::transform()
> > > Example:
> > > // before proposal
> > > int x = try_generate_foo().transform([](Foo& f){ return f.bar; });
> > >
> > > // after proposal
> > > int x = try_generate_foo().transform(&Foo::bar);
> > >
> > > This is similar to how the projections of the ranges algorithms allow pointer-to-members to be passed.
> > > If this proposal idea goes further it should be considered whether the exact same INVOKE semantics [1] should
> > > apply here.
> >
> > These writings look a bit off: transform has to return another optional,
> > not a value. Did you mean to write "optional<...> x"?
>
>
> Yes, you are completely right. Sorry for the confusion.
>
>
> > In any case, transform today is *already* specified to use std::invoke /
> > invoke_result_t. What stops the second statement from Just Working™ is
> > the fact that, for it to have any sense, it has to return an optional
> > *reference* and we don't have those yet.
> >
> > (In fact, note that the two statements above are not equivalent.)
> >
> > Therefore, there's this Mandates clause in place that blocks that condition:
> >
> > > https://eel.is/c++draft/optional#monadic-11
> >
> > > Mandates: U is a non-array object type
> >
> > which is false, U would be `int &&` and that's not an object type.
>
>
> Again, you are completely right.
> I guess what I want is that in the case of pointer-to-member-data the member would be copied to the new optional.
> But this would mean that the semantics differ from those of std::invoke which makes it harder to argue for.

More importantly, it would take up design space in the event that
`optional<T&>` came into existence.