@nogc and lambdas
Manu
turkeyman at gmail.com
Wed Oct 30 15:25:06 UTC 2024
I'm finding it extremely inconvenient to write @nogc event-driven code when
I can't use lambdas because they always want to allocate closures when they
shouldn't be.
Can anyone take a look at this issue:
https://issues.dlang.org/show_bug.cgi?id=24838
The problem is this:
class MyClass
{
void doSomething();
void myMethod() @nogc
{
acceptsCallback(¬Lambda); // this works; delegate is
created from the method
acceptsCallback((){ doSomething(); }); // doesn't work!
closure needlessly tries to allocate
}
void notLambda()
{
doSomething();
}
}
Here we have a method that calls some kind of async that receives a
callback.
Obviously, I can pass a method at a callback as shown in the first line of
myMethod; but the second line, where I pass the same code as a lambda fails.
The problem here is that the language is trying to allocate a closure
around `this` because the lambda calls another method.
This is totally redundant; there's no need to allocate a closure if `this`
is the only thing that's captured... because it should just accept `this`
as the context directly!
This lambda isn't a closure, it's a METHOD.
The compiler needs to determine that `this` is the only capture, and then
abandon the closure and synthesise the lambda as a regular method.
This will make lambda's about 100x more useful in @nogc code. And even if
you don't care about @nogc; it also eliminates a common source of garbage,
and a pointless double-indirection when accessing `this` via another
redundant `this`.
I can't think of any time I've ever written a lambda that I actually *want*
to allocate a closure to access latent local scope data, but I almost
always refer to sibling members of the calling function to implement some
sort of callback response.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20241031/9afa2549/attachment.htm>
More information about the Digitalmars-d
mailing list