Add GC-free closures to D. Less GC reliance means less memory fragmentation, enabling lower-level uses of D to use closures.

This has precedent in C blocks and in C++'s lambdas.

On Thursday, 5 September 2019 at 14:46:08 UTC, James Lu wrote:
> Add GC-free closures to D. Less GC reliance means less memory fragmentation, enabling lower-level uses of D to use closures.
>
> This has precedent in C blocks and in C++'s lambdas.

The first question should be, does the current closure semantics support GC-free deallocation?

On Thursday, 5 September 2019 at 14:46:08 UTC, James Lu wrote:
> Add GC-free closures to D. Less GC reliance means less memory fragmentation, enabling lower-level uses of D to use closures.
>
> This has precedent in C blocks and in C++'s lambdas.

1)
> import std;
>
> auto mul(R)( R r, int n) /*@nogc*/ {
>     // simple GCed version
>     return r.map!( e => e*n);
> 
>     // more complicated but noGC version
>     //return zip( r, n.repeat).map!( z => z[0]*z[1]);
> }
> 
> void main() {
>     iota( 0, 10).mul( 5).writeln;
> }

2) lambda can capture something that stored in GC memory(array,AA,class,new struct,..)
  so for right working (GC:mark/scan) lambda also should be allocated in GC memory.
  (opposite: RCed-lambda, emplace, GC.addRange/remove)

On Thursday, 5 September 2019 at 15:17:04 UTC, a11e99z wrote:
> On Thursday, 5 September 2019 at 14:46:08 UTC, James Lu wrote:
>> Add GC-free closures to D. Less GC reliance means less memory fragmentation, enabling lower-level uses of D to use closures.
>>
>>     // more complicated but noGC version
>>     //return zip( r, n.repeat).map!( z => z[0]*z[1]);

more complicated visually and thoughtful but machine code probably simpler and faster

On Thursday, 5 September 2019 at 14:50:31 UTC, James Lu wrote:
> The first question should be, does the current closure semantics support GC-free deallocation?

AFAIK, closure is allocated with _d_allocatememory hook. If you override it, you can use your preferred allocator there.