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.
