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.
