Binding rvalues to ref parameters redux

Manu turkeyman at gmail.com
Sun Mar 31 21:35:48 UTC 2019


On Sun, Mar 31, 2019 at 2:28 PM Manu <turkeyman at gmail.com> wrote:
>
> `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.

~~, and not temporaries.~~ - sorry, tail from a re-written sentence.
That should read "and not lvalue references".


More information about the Digitalmars-d mailing list