> On May 26, 2019, at 9:15 PM, Ben Grasset <operato...@gmail.com> wrote: > > 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
Right now as Blaise designed them they’re totally tied to interfaces. I tried to make a record version from this code but ran into too many problems I couldn’t solve and gave up. The easiest thing to do afaik is making nested proc vars allow anonymous functions and turn this on automatically if it was decided the method doesn’t have captures and/or doesn’t get passed outside of scope. I already did this work some months ago (https://github.com/genericptr/freepascal/tree/anon_funcs) and it worked remarkably well (nested proc vars already do all the work required but they used records for the backing store). Regards, Ryan Joseph _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
