On Wed, Jan 30, 2019 at 6:40 PM Nicholas Wilson via Digitalmars-d-announce <digitalmars-d-announce@puremagic.com> wrote: > > On Wednesday, 30 January 2019 at 18:29:37 UTC, Manu wrote: > > On Wed, Jan 30, 2019 at 9:20 AM Neia Neutuladh via > > Digitalmars-d-announce <digitalmars-d-announce@puremagic.com> > > wrote: > >> 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...? > > Why is the cast being attempted? 'p' is an lvalue, and whatever > > that does should remain exactly as is (ie, emits a compile > > error). > > > > 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. > > It appears to say it does: > > fun(my_short); // implicit type conversions (ie, short->int > promotion) > > You should clarify that ;)
Yes, as said above, read `short(10)`. I can understand the confusion that it may look like a variable when taken out of context; but listed beneath the heading immediately above which says: "This inconvenience extends broadly to every manner of **rvalue** passed to functions" It didn't occur to me the reader might interpret the clearly stated list of cases of rvalues passed to functions to include arguments that are not rvalues. The name was just chosen to indicate the argument is a short, perhaps an enum, or any expression that is a short... I could have used `short(10)`, but apparently I didn't think of it at the time. Is this the basis for the claims of "a hole you could drive a truck through"? Again, a request for clarification, and a couldn't-possibly-be-more-trivial revision may resolve this.
