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

[Andrei Alexandrescu]

On 1/30/19 10:12 PM, Manu wrote:
> On Wed, Jan 30, 2019 at 7:05 PM Nicholas Wilson via
> Digitalmars-d-announce <digitalmars-d-announce at puremagic.com> wrote:
>>
>> On Thursday, 31 January 2019 at 02:10:05 UTC, Manu wrote:
>>> On Wed, Jan 30, 2019 at 1:05 PM Andrei Alexandrescu via
>>>> 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?
>>
>> I think so.
>>
>>>> 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.
>>
>> It would.
>>
>>>> * 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".
>>
>> You should just PR it back to review
> 
> I can't do that, it's been rejected, with mostly incorrect rejection
> text affixed to the bottom.
> 
>> with that fix and a note
>> about how it lowers to statements (incl. an example of
>> lambdification for if/while/for/switch statements (see
>> https://forum.dlang.org/post/qysmnatmjquuhylaqumm@forum.dlang.org
>> ))
> 
> I'm pretty sure that's not necessary. I haven't understood why this
> noise about expressions. This DIP applies to statements.
> I can't see how there's any problem with the lowering if the statement
> is a control statement?
> 
> if (ref_fun(10)) { ... }
> ==>
> {
>    int __tmp = 10;
>    if (ref_fun(__tmp)) { ... }
> }
> 
> What's the trouble?

The trouble is major.

Replace "if" with "while":

while (ref_fun(10)) { ... }
==>
{
   int __tmp = 10;
   while (ref_fun(__tmp)) { ... }
}

That means ref_fun is called with the same lvalue multiple times. In all 
likelihood this is not what you want!

A possible retort is: "Of course, while would not be lowered that way, 
but a slightly different way!" etc. The point is, ALL OF THAT must be in 
the DIP, not assumed obvious or clarified in informal discusson outside 
the DIP.

Again: please be thorough, state your assumptions, cover all cases.