Subject: Re: [std-proposals] Operator for reference casting
From: Jason McKesson (jmckesson_at_[hidden])
Date: 2021-01-16 11:27:05
On Sat, Jan 16, 2021 at 11:39 AM Bengt Gustafsson via Std-Proposals
> Given that a language feature has more wiggle room we could define two
> different operators with limitations in applicability that can't be
> enforced for a library feature such as std::forward / std::move.
> prefix -> is a forwarding operator which can only be applied to
> universal references, i.e. parameters declared with deduced template
> type and a && modifier.
And what of `auto &&t = expr;`? In terms of the rules for how `t` gets
deduced, it is just as much a forwarding reference as a parameter. And
it's just as reasonable to want to forward `t` as you would for any
parameter. And yet, the standard's definition of "is a forwarding
reference" would not include `t`.
I don't think it's reasonable to have language be functional or
non-functional based on nebulous properties like "is a forwarding
> prefix => is a move operator which can only be applied to by value
> variables and rvalue references (excluding universal references!).
So if a function returns an lvalue reference, you can't move from it?
> In line with what I wrote before this means that the two operators would
> have disjunct areas of applicability (you never have a choice as to
> which one to apply, in each instance one or the other will be a
> compilation error). So do we add or reduce confusion by having two
> distinct spellings? I don't know, what do you think?
> There is a possible tactical advantage with this definition in that it
> is not possible to implement it in the library. The motivation for
> introducing it as a language feature could thus be higher. This relies
> on an urge to reduce the risks with the status quo, which if you as me
> is not really the problem we're actually trying to solve; it is the
> verbosity of std::forward.
My understanding is that one of the problems of `std::forward` is that
heavy usage of it actually impacts compile times, to the point where
some libraries just do the whole `static_cast` bit directly. So it's
not *just* a matter of verbosity.
STD-PROPOSALS list run by email@example.com
Standard Proposals Archives on Google Groups