DIP 1016 should use expression lowering, not statement lowering

[Steven Schveighoffer]

On 1/29/19 6:52 AM, Andrei Alexandrescu wrote:
> While writing this example:
> 
> int[] a = cast(int[]) alloc.allocate(100 * int.sizeof);
> if (alloc.reallocate(a, 200 * int.sizeof))
> {
>      assert(a.length == 200);
> }
> 
> =====>
> 
> int[] a = cast(int[]) alloc.allocate(100 * int.sizeof);
> void[] __temp0 = a;
> if (alloc.reallocate(__temp0, 200 * int.sizeof)
> {
>      assert(a.length == 200);
> }
> 
> I noticed a problem - the lowering as informally described in DIP 1016 
> makes it difficult to figure how function calls present in control 
> statements like if, while, etc. should behave. Where should the 
> temporary go? An expression-based lowering clarifies everything. A 
> statement-based lowering would need to work on a case basis for all 
> statements involving expressions.

I don't think it's very difficult or confusing. Any rvalue in any 
expression that requires ref should be implicitly declared before the 
statement that contains the expression, and include a new scope:

<statement involving rvalues r1, r2, r3, ... rN>

---->

{
    auto _tmpr1 = r1;
    auto _tmpr2 = r2;
    auto _tmpr3 = r3;
    ...
    auto _tmprN = rN;
    <statement with _tmpr1, _tmpr2, _tmpr3, ... _tmprN>
}

Essentially, nothing is different from existing semantics today, when 
rvalues are used and provides reference semantics (yes, it's possible, 
see tempCString). They live until the end of the statement. It's how 
this has to be. It can't be expression based.

-Steve