[fpc-devel] Closures/anonymous functions update

Ben Grasset operator97 at gmail.com
Mon May 27 03:15:21 CEST 2019

On Sat, May 18, 2019 at 2:57 PM Ryan Joseph <ryan at thealchemistguild.com>

> I wanted to make an alternate capture mode as an optimization for closures
> that don’t get passed outside of their scope but I wasn’t able to figure
> this out yet (using old-style objects instead of classes). It’s a waste to
> allocate a new class if not needed (this would hurt realtime graphics
> applications badly) so that should be tackled eventually. Maybe they can be
> made to inline or something, not sure how to handle it though.

Even if it doesn't happen right away, I 100% agree that this needs to be
how they work eventually (which will not break Delphi compatibility,
because how they work internally is irrelevant as long as the external
means to access / use anonymous functions is roughly the same.)

Currently I actually tend to avoid anonymous functions in Delphi for
"small" callback-esque use cases where no capturing happens, because they
*are* in fact objectively slower than function pointers due to how they
allocate and destroy a class instance on every call (for no good reason.)

That is *not* how they work in most languages, for anyone skeptical, BTW.
Every existing not-Delphi "native" compiler, for a multitude of different
languages, that implements anonymous functions in some way not only *does
not* allocate anything on the heap in non-capturing cases, but in fact
fully inlines them thus completely eliminating the function call overhead
as well.

That ties in to how I'd also love to see FPC be able to inline normal
"procvars" like most compilers do, but I suppose that's a different story...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20190526/71a31d88/attachment.html>

More information about the fpc-devel mailing list