C++ Logo

STD-PROPOSALS

Advanced search

Subject: Re: [std-proposals] Operator for reference casting
From: Jason McKesson (jmckesson_at_[hidden])
Date: 2021-01-15 16:51:42


On Fri, Jan 15, 2021 at 10:27 AM Barry Revzin via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
>
>
> On Fri, Jan 15, 2021 at 7:49 AM Jean-Baptiste Vallon Hoarau via Std-Proposals <std-proposals_at_[hidden]> wrote:
>>
>> Hello everyone,
>>
>> I think you are all aware how verbose perfect forwarding is. I haven't seen any proposal that could tackle this (admittedly minor) issue so far, except the one on hygienic macros.
>> So what if we had an operator for casting to a reference?
>> For example, given a value x, than the following could be equivalent :
>> x& -> static_cast<decltype(x)&>(x)
>> x&& -> static_cast<decltype(x)&&>(x)
>>
>> This would make forwarding a lot less cumbersome to write/read (goodbye decltype(x)(x), hello x&&). However, I don't see many use cases for explicit lvalue cast, and this would be at odd with lambda capture syntax.
>>
>> Let me know what you think.
>> -Jean-Baptiste
>
>
> I'd written this a while ago (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0644r1.html), which would be a prefix operator >> for forwarding. This got rejected in 2017, >> is just a bad choice in the context of templates which are already using a lot of angle brackets.
>
> Prefix && is a gcc extension so isn't an option. Postfix && looks like it's starting the beginning of a logical conjunction.
>
> In discussion of my paper, the possibility of a good-but-nonconflicting keyword was brought up and people suggested declfwd (vote was 0-10) and fwdexpr (vote was 7-5). The best option here seems to be to add some kind of hygienic macro language feature such that we can introduce std::fwd(x) to actually be a function that does forwarding.

I recall that for a time, P0849 which makes `auto(expr)` create a
prvalue of the appropriate type also included `decltype(auto)(expr)`
being equivalent to `std::forward<decltype(expr)>(expr)`. The
committee decided against that, on the grounds of:

> disliked its expert-friendly nature, and concluded that adding this facility would cause the teaching effort to add up.

Which given the convoluted spelling, you can't really disagree with.


STD-PROPOSALS list run by std-proposals-owner@lists.isocpp.org

Standard Proposals Archives on Google Groups