<div dir="auto"><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Ryan Joseph via fpc-pascal <<a href="mailto:fpc-pascal@lists.freepascal.org">fpc-pascal@lists.freepascal.org</a>> schrieb am Mo., 8. Nov. 2021, 15:31:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
> On Nov 8, 2021, at 1:27 PM, Sven Barth via fpc-pascal <<a href="mailto:fpc-pascal@lists.freepascal.org" target="_blank" rel="noreferrer">fpc-pascal@lists.freepascal.org</a>> wrote:<br>
> <br>
> 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.<br>
<br>
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.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">I don't know what you mean with "new function body". If a function is inlined its code is contained within the surrounding function and if it's not inlined then nothing changes. </div><div dir="auto"><br></div><div dir="auto">Regards, </div><div dir="auto">Sven </div></div>