Date: Sun, 09 Jun 2024 23:14:58 +0200
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.
It would also raise the question what the behavior should be when you pass a pointer-to-member-function which returns a
reference. Should that be allowed and copy or should it be disallowed?
>
> > 2. Add the ability to call a function to create a default value.
>
> https://github.com/cplusplus/papers/issues/921
>
> Was proposed as value_or_else.
Thanks, for pointing this out. Looks pretty much like what I had in mind.
>
> My 2 c,
> --
> Giuseppe D'Angelo
>
Thanks,
Lorenz
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.
It would also raise the question what the behavior should be when you pass a pointer-to-member-function which returns a
reference. Should that be allowed and copy or should it be disallowed?
>
> > 2. Add the ability to call a function to create a default value.
>
> https://github.com/cplusplus/papers/issues/921
>
> Was proposed as value_or_else.
Thanks, for pointing this out. Looks pretty much like what I had in mind.
>
> My 2 c,
> --
> Giuseppe D'Angelo
>
Thanks,
Lorenz
Received on 2024-06-09 21:15:00