DIP 1016--ref T accepts r-values--Formal Assessment

Olivier FAURE couteaubleu at gmail.com
Fri Feb 1 23:22:20 UTC 2019


On Thursday, 31 January 2019 at 21:50:32 UTC, Steven 
Schveighoffer wrote:
> How is the problem not in doubleMyValue? It's sole purpose is 
> to update an lvalue. It is the perfect candidate to mark with 
> @disable for rvalues.

But right now, updating an rvalue is what ref is supposed to be 
used for.

Besides, the fact remains that accepting DIP 1016 would add a new 
corner case with the potential to create hard-to-detect bugs, 
which feels to me like it should be a dealbreaker. The fact that 
this corner case can be patched using @disable isn't good enough, 
because:
- Existing codebases that use ref won't have the @disable patch, 
which means using them will become (slightly) dangerous because 
of DIP 1016.
- Making libraries that behave predictably should be the default 
path (the "pit of success" philosophy), not require an additional 
construct.

Besides, D's type system should be more than capable of 
consistently telling the user "Be careful, you're modifying a 
temporary when it's probably not what you meant".

---

An alternate proposal that just came to mind: allowing the user 
to pass rvalues to ref arguments with the following syntax:

     y = doubleMyValue(cast(ref)10);

This syntax would avoid creating ambiguous situations where the 
compiler thinks you're passing it a getter's return as a 
temporary when you're trying to pass the attribute that the 
getter maps to. Eg, the following code:

     y = doubleMyValue(pt.x);

would still fail the same way it currently does when Point.x() is 
a getter.


More information about the Digitalmars-d-announce mailing list