Binding rvalues to ref parameters redux

[Manu]

`On Thu, Mar 28, 2019 at 1:15 PM Andrei Alexandrescu via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
>
> On 3/28/19 3:59 PM, bitwise wrote:
> > I agree that the nonassignability requirement fills a major pothole, but
> > it doesn't address the issue of expressing your intent as the writer of
> > a function with ref parameters. The caller may have trouble determining
> > if a function will modify the argument passed to it. The issue could be
> > mitigated by function/parameter naming convention, comments,
> > documentation, or providing source code to the caller, but all of these
> > solutions have the potential to be spotty or absent, so I believe
> > something should be done to make the writer's intent clear to the caller.
>
> A salient point.
>
> Also made in the DIP as "In such cases, w.price is not assignable and
> calls such as applyDiscount(w.price) or w.price.applyDiscount will
> succeed but not perform any meaningful update. A maintainer expecting
> such calls to fail may be surprised. We consider this is an inevitable
> price to pay for the gained flexibility."
>
> I reckon that there's implied that some sort of @rvalue attribute would
> be a better solution, a la void fun(@rvalue ref T). I'm afraid this
> would be widely protested,

See, I would read `void fun(@rvalue ref T)` as a *completely* different thing.
If that were in the language, I would expect that to be an
rvalue-reference, and as such may absolutely only accept rvalues, and
not temporaries.

I also think there's room on the language for both things, but I
always thought rvalue-references were a contentions non-starter,
because D has implicit move semantics, and it never seemed to me like
anyone wanted to explore explicit move semantics. This talk about move
constructors seems to have opened that conversation.