On Wed, Jan 30, 2019 at 1:05 PM Andrei Alexandrescu via Digitalmars-d-announce <[email protected]> wrote: > > 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.
What? `expr` must be an rvalue... if it's not, then none of this applies. > > 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) > ======== Oh I see. > fun(short(10)); // implicit type conversions (ie, short->int promotion) I did not intend for this DIP to apply to anything other than rvalues. I can totally see how that's not clear. `my_short` should be an rvalue of some form, like the rest. Is that the only such line? > Presumably my_short is a variable of type short. Is that correct? It is not. It should be an rvalue like everything else. Perhaps it's an enum... but I should write `short(10)`, that would be clear. > Again (this is not a rhetorical or sarcastic question): are you sure DIP > 1016 expresses what you are trying to accomplish? Fairly certain. > > 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. I still can't see a truck-sized hole. > * The problem goes undetected in community review. I don't know how I could have influenced this outcome. > * Its own author seems to not have an understanding of what the DIP > proposes. More classy comments. I can't get enough of the way you belittle people. I made a 1-word error, where I should have written `short(10)` to be clear. 1-word error feels amendment-worthy, and not a call for "let's start over from scratch".
