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.
