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;
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;
void bump(ref int x) { ++x; }
short y = 42;
     int __temp0 = y;

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?


More information about the Digitalmars-d-announce mailing list