What does 'inline' mean?

[Walter Bright]

On 6/7/2020 11:14 PM, Manu wrote:
> I think a first part of the conversation to understand, is that since D doesn't 
> really have first-class `inline` (just a pragma, assumed to be low-level 
> compiler control), I think most people bring their conceptual definition over 
> from C/C++, and that definition is a little odd (although it is immensely 
> useful), but it's not like what D does.

C/C++ inline has always been a hint to the compiler, not a command.


> In C/C++, inline says that a function will be emit to the binary only when it is 
> called, and the function is marked with internal linkage (it is not visible to 
> the linker from the symbol table)
> By this definition; what inline REALLY means is that the function is not placed 
> in the binary where it is defined, it is placed in the binary where it is 
> CALLED, and each CU that calls an inline function receives their own copy of the 
> function.

Why does it matter where it is emitted? Why would you want multiple copies of 
the same function in the binary?


> Another take on inline, and perhaps a more natural take (if your mind is not 
> poisoned by other native languages), is that the function is not actually emit 
> to an object anywhere, it is rather wired directly inline into the AST instead 
> of 'called'. Essentially a form of AST macro.

The problem with this is what is inlined and what isn't is rather fluid, i.e. it 
varies depending on circumstances and which compiler you use. For example, if 
you recursively call a function, it's going to have to give up on inlining it. 
Changes in the compiler can expand or contract inlining opportunities. Having it 
inline or issue an error is disaster for compiling existing code without 
constantly breaking it.


> I reach for inline in C/C++ for various different reasons at different times, 
> and I'd like it if we were able to express each of them:
> 
> 1. I only want the function to be present in the CALLING binary. I do not want 
> an inline function present in the local binary where it was defined (unless it 
> was called internally). I do not want a linker to see the inline function 
> symbols and be able to link to them externally. [This is about linkage and 
> controlling the binary or distribution environment]

Why? What is the problem with the emission of one copy where it was defined?


> 2. I am unhappy that the optimiser chose to not inline a function call, and I 
> want to override that judgement. [This is about micro-optimisation]

It's not always possible to inline a function.


> 3. I want to treat the function like an AST macro; I want the function inserted 
> at the callsite, and I want to have total confidence in this mechanic. [This is 
> about articulate mechanical control over code-gen; ie, I know necessary facts 
> about the execution context/callstack that I expect to maintain]

The PR I have on this makes it an informational warning. You can choose to be 
notified if inlining fails.


> Are there non-theoretical use cases I've missed that people have encountered?

At its root, inlining is an optimization, like deciding which variables go into 
registers.