On Sat, Jan 16, 2021 at 11:39 AM Bengt Gustafsson via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> 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
reference".

> 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.