Binding rvalues to ref parameters redux
Andrei Alexandrescu
SeeWebsiteForEmail at erdani.org
Thu Mar 28 20:11:26 UTC 2019
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, even more widely than doing nothing or going
with the nonassignable requirement. You are of course encouraged to say
what you think is right and raise the matter to other folks as well.
The nonassignable requirement is a major improvement, but won't catch
all potential misuses. I don't know how to do better.
More information about the Digitalmars-d
mailing list