Binding rvalues to ref parameters redux

Rubn where at is.this
Thu Mar 28 20:17:25 UTC 2019


On Thursday, 28 March 2019 at 20:11:26 UTC, Andrei Alexandrescu 
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, 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.

I liked the idea someone else gave in regards to "out". I think 
it would be too difficult to repurpose out as it is now, but 
perhaps even just "out ref" would do.


     void foo(out ref int value);

     int v;
     foo(out v);

It would be have the same way as C#, but again how many different 
type of attributes are there going to be. I honestly think there 
are too many, and the current way in/out are implement, they 
should just be deprecated. They don't add that much value.


More information about the Digitalmars-d mailing list