DIP 1016 should use expression lowering, not statement lowering

[Andrei Alexandrescu]

On 1/29/19 10:44 AM, Nicholas Wilson wrote:
> On Tuesday, 29 January 2019 at 11:52:40 UTC, 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.
> 
> On the contrary, an expression lowering cannot inject temporary 
> declarations and is impossible.
> 
> The correct lowering in the case for `if` & friends follows the form of 
> C++ initialiser conditions(?) i.e:
> 
>   if (auto val = expr(); val) { ... },

Since we don't have these constructs, lowering would need to explain 
what happens here. Not difficult, but would be nice if we could avoid.

>   or the slightly more ugly valid D:
> 
>   if ((){return expr(); }()) { ... }
> 
> this lambdification will work for just about anything: if, while, assert...

Yes, converting to lambdas is nice and easy and requires no statement 
enumeration - just lower expressions to lambdas and be done with it. 
It's okay if the resulting code is ugly, it won't be user-visible.