DIP 1016--ref T accepts r-values--Formal Assessment
Andrei Alexandrescu
SeeWebsiteForEmail at erdani.org
Tue Jan 29 11:15:02 UTC 2019
On 1/29/19 1:01 AM, Manu wrote:
> This DIP is about passing rvalues to ref... so the issue you describe
> passing lvalues to ref does not apply here.
> There is no suggestion to change lvalue rules anywhere in this DIP.
The problem is with rvalues resulting as temporaries from lvalues. As in:
void bump(ref int x) { ++x; }
short y = 42;
bump(y);
assert(y == 43); // oops
This is a smoking gun. If DIP 1016 does not propose allowing the code
above, it has caused a gross misunderstanding. Similarly, you mention in
a different response:
> 4. "Under DIP 1016, a call with any T[] will silently "succeed" by
> converting the slice to void[]" <-- Do you mean "... with any T[]
> rvalue ..."? What would be the aim of that call? Can you suggest a
> particularly sinister construction?
If your intent was to NOT allow rvalues resulting from conversions, it
didn't come through at all. On the contrary, some examples suggest DIP
1016 _does_ allow it, as in this example:
========
This inconvenience extends broadly to every manner of rvalue passed to
functions, including:
...
fun(my_short); // implicit type conversions (ie, short->int promotion)
========
The reader assumes since the DIP characterizes passing a short lvalue to
a ref int is an inconvenience, the DIP has set out to resolve it.
The lowering rules proposed by DIP 1006 prescribe the following:
void bump(ref int x) { ++x; }
short y = 42;
bump(y);
===>
void bump(ref int x) { ++x; }
short y = 42;
{
int __temp0 = y;
bump(__temp0);
}
So... yes, lvalues do (undesirably) get converted to rvalues of a
different type according to the DIP.
Are you sure the DIP expresses what you are trying to accomplish?
Andrei
More information about the Digitalmars-d-announce
mailing list