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
