Alternative to Interfaces

[Kagamin]

On Friday, 18 January 2019 at 18:48:46 UTC, Jonathan M Davis 
wrote:
> Yes, but some D features will use the GC

They would like to allocate, but they don't know nor care where 
it's allocated from, if the developer uses custom memory 
management, he will know how it's allocated and will be able to 
manage it.

> The list of such features is short, but delegates are on it.

Closures are, but not delegates. Delegate is just a pair of 
pointers, you don't need to allocate at all to keep them around, 
similar to slices. They even work in betterC.

> get around the allocations in some cases, but in general, if 
> you use delegates, you're going to allocate with the GC.

Custom memory management is obviously not the general case.

> but the allocations that happen for delegates and lambdas is 
> one of the biggest reasons that some folks avoid std.algorithm 
> and complain that it allocates. That's what happens when you 
> pass stuff that the compiler decides has to have closures 
> allocated for it.

Is it really blocked? I got this to work with dip1000:

@safe @nogc:
alias int delegate(int) @safe @nogc dg;
struct Map(T)
{
     private T a;
}
Map!dg map(return dg b)
{
     Map!dg m;
     m.a=b;
     return m;
}
void f()
{
     int a;
     auto b=map(i=>a);
     a=b.a(0);
}

Templated function can't infer closure type for some reason.