> On Nov 8, 2021, at 1:27 PM, Sven Barth via fpc-pascal > <fpc-pascal@lists.freepascal.org> wrote: > > And there you have it (simplified obviously). As long as the compiler can > determine *at compile time* the code of the function (and the function is > inlineable) it should in theory be able to inline it. This is true no matter > if it's a function variable, a method variable (pointing to a non-virtual > method) or an anonymous function. However if somewhere between passing in the > function address and calling the function inlining does not work for one > reason or the other (e.g. due to open array parameters which are currently > not supported by inlining) then the compiler obviously can't inline the > provided function either.
Interesting, so the inlining the containing function is the key. I guess if the container were not inlined it would basically be like a generic where a new function body would be generated which contained the inline function pointers body with arguments replaced. For example: function Map_MultBy2(aArr: TLongIntArray): TLongIntArray; begin SetLength(Result, Length(aArr)); for i := 0 to High(aArr) do Result[i] := aArr[i] * 2; { MultBy2 is inlined here } end; Regards, Ryan Joseph _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal