Date: Thu, 5 Jan 2023 20:57:47 -0500
On 1/5/23 20:35, Jason McKesson via Std-Proposals wrote:
> On Thu, Jan 5, 2023 at 7:44 PM Phil Bouchard via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
>> Greetings,
>>
>> Please find attached a small wrapper function that could be useful as a replacement for forward<>() which uses explicit type specification (for some reason),
> There is a reason. The fact that you don't know what that reason is is
> why `pass` can't actually do what you claim. The odd thing is, your
> code doesn't even show you replacing `forward`; `::foo` still uses
> `forward`.
The forward<>() in the code is an example of the old usage.
>
> `std::forward` is meant to be used in perfect forwarding scenarios.
> This means you have a forwarding reference. Your example only uses
> `pass` with a non-template function. So forwarding references aren't
> around.
>
> Really, your `pass` is no different than using `std::move`. If I make
> a `foo_pass` template that's like `foo` except that you use `pass`
> rather than `std::forward`, then it does the wrong thing:
> https://gcc.godbolt.org/z/EMndz1xds
Oh I didn't know move() is effective for l-values and a no-op for r-values.
>
> So this `pass` is absolutely not a replacement for `std::forward`. It
> cannot be used for perfect forwarding.
>
>> shorter to type and can be used as perfect forwarding for virtual functions as well,
> Virtual functions cannot be templates and therefore cannot have
> "perfect forwarding". I think you need to take some time to learn what
> that term actually refers to.
That's fine thanks, I understand myself. So I can go ahead with a meta
universal syntax because this is really what I am looking for.
>
>> not only with template functions. You can use it for universal parameter types as well.
> On Thu, Jan 5, 2023 at 7:44 PM Phil Bouchard via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
>> Greetings,
>>
>> Please find attached a small wrapper function that could be useful as a replacement for forward<>() which uses explicit type specification (for some reason),
> There is a reason. The fact that you don't know what that reason is is
> why `pass` can't actually do what you claim. The odd thing is, your
> code doesn't even show you replacing `forward`; `::foo` still uses
> `forward`.
The forward<>() in the code is an example of the old usage.
>
> `std::forward` is meant to be used in perfect forwarding scenarios.
> This means you have a forwarding reference. Your example only uses
> `pass` with a non-template function. So forwarding references aren't
> around.
>
> Really, your `pass` is no different than using `std::move`. If I make
> a `foo_pass` template that's like `foo` except that you use `pass`
> rather than `std::forward`, then it does the wrong thing:
> https://gcc.godbolt.org/z/EMndz1xds
Oh I didn't know move() is effective for l-values and a no-op for r-values.
>
> So this `pass` is absolutely not a replacement for `std::forward`. It
> cannot be used for perfect forwarding.
>
>> shorter to type and can be used as perfect forwarding for virtual functions as well,
> Virtual functions cannot be templates and therefore cannot have
> "perfect forwarding". I think you need to take some time to learn what
> that term actually refers to.
That's fine thanks, I understand myself. So I can go ahead with a meta
universal syntax because this is really what I am looking for.
>
>> not only with template functions. You can use it for universal parameter types as well.
-- Email Signature Logo <https://www.fornux.com/> *Phil Bouchard* facebook icon <https://www.linkedin.com/in/phil-bouchard-5723a910/> CTO T: (819) 328-4743 E: phil_at_[hidden]| www.fornux.com <http://www.fornux.com> 8 rue de la Baie| Gatineau (Qc), J8T 3H3 Canada Banner <https://goglobalawards.org/> Le message ci-dessus, ainsi que les documents l'accompagnant, sont destinés uniquement aux personnes identifiées et peuvent contenir des informations privilégiées, confidentielles ou ne pouvant être divulguées. Si vous avez reçu ce message par erreur, veuillez le détruire. This communication (and/or the attachments) is intended for named recipients only and may contain privileged or confidential information which is not to be disclosed. If you received this communication by mistake please destroy all copies.
Received on 2023-01-06 01:57:48