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

[Andrei Alexandrescu]

On 1/30/19 1:29 PM, Manu wrote:
> On Wed, Jan 30, 2019 at 9:20 AM Neia Neutuladh via
> Digitalmars-d-announce <digitalmars-d-announce at puremagic.com> wrote:
>>
>> On Wed, 30 Jan 2019 09:15:36 -0800, Manu wrote:
>>> Why are you so stuck on this case? The DIP is about accepting rvalues,
>>> not lvalues...
>>> Calling with 'p', an lvalue, is not subject to this DIP.
>>
>> The result of a CastExpression is an rvalue. An implicit cast is a
>> compiler-inserted CastExpression. Therefore all lvalues with a potential
>> implicit cast are rvalues.
> 
> But there's no existing language rule that attempts to perform an
> implicit cast where an lvalue is supplied to a ref arg...?

That's exactly what lowerings are for: to precisely specify what should 
happen when the proposed construct is used. DIP 1016 proposes a lowering 
of the form:

{
   T __temp0 = expr;
   fun(__temp0);
}

In the first step, an implicit conversion of an lvalue may take place.

> Why is the cast being attempted? 'p' is an lvalue, and whatever that
> does should remain exactly as is (ie, emits a compile error).

Not according to DIP 1016. Here is an example pasted from it:

========
This inconvenience extends broadly to every manner of rvalue passed to 
functions, including:
...
fun(my_short); // implicit type conversions (ie, short->int promotion)
========

Presumably my_short is a variable of type short. Is that correct?

Again (this is not a rhetorical or sarcastic question): are you sure DIP 
1016 expresses what you are trying to accomplish?

> We could perhaps allow this for `const` args, but that feels like
> separate follow-up work to me, and substantially lesser value. This
> DIP doesn't want to change anything about lvalues.

What we have here is:

* DIP 1016 proposes a hole in the language one could drive a truck through.

* The problem goes undetected in community review.

* Its own author seems to not have an understanding of what the DIP 
proposes.


Andrei