On 1/30/19 1:29 PM, Manu wrote:
On Wed, Jan 30, 2019 at 9:20 AM Neia Neutuladh via
Digitalmars-d-announce <[email protected]> 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
