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

[Manu]

On Wed, Jan 30, 2019 at 6:40 PM Nicholas Wilson via
Digitalmars-d-announce <digitalmars-d-announce at 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 at 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.