Adding a trampoline means making the calls slower.

Even if the lambda were to inline the call, it still would be a completely different location in the executable image.

It's almost never used. The delegate version is almost universally used.

> Even if the lambda were to inline the call, it still would be a completely different location in the executable image.

Not sure what you mean. Inlined code is not in a different location, it's right where one is executing! Also, optimizers are pretty darned good these days.

Both the member function and the lambda are their own symbols with their own machine code -- might not even be possible for them to be the same code due to ABI concerns.

Even if they're the same code, I don't think it's that easy for linkers to merge them?

Inlining can happen in several places - the front end, the optimizer, or the link step. The process of inlining removes the need for the symbol for the inlined function.

I recommend writing some code snippets, compile them with inlining on, and looking at the resulting assembler code.

Generally inlining can happen way earlier than linking. E.g. Virgil's compilation model doesn't have a linker at all, it's a whole-program compiler, and that works pretty well, even for 50KLOC programs.

That's not the problem I pointed out at all.

For a trampoline to have no overhead, you need the call to the trampoline to be changed to a call to the underlying function.

That's not an optimization that can easily happen due to the traditional compilation model.

Even if inlining were to happen, you end up with bloat, and few compilers are able to merge similar code like this (which can only happen at link-time, obviously, since the functions might be in different translation units). This optimization is known as ICF, and is not commonly enabled.

In practice I don't think the inliner takes ICF into consideration when deciding whether to inline anyway, so you just end up calling a function that calls another function.

> due to the traditional compilation model.

You're talking about C/C++'s compilation model and ABI and there are plenty of others. ICF is a hack to deal with C++'s naive template expansion. There are lots of other languages that don't work that way at all and don't need a linker optimization like that.

ICF is important to fold equivalent lambdas as well.

All compiled languages virtually use the C model of doing things, often including its FFI.