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

[Manu]

On Wed, Jan 30, 2019 at 1:05 PM Andrei Alexandrescu via
Digitalmars-d-announce <digitalmars-d-announce at puremagic.com> 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 <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.

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".