What does 'inline' mean?

[Basile B.]

On Monday, 8 June 2020 at 06:14:44 UTC, Manu wrote:
> Inline has been bugging me forever, it's usually not what I 
> want. The spec says this-or-that, but I think we should take a 
> step back, ignore what's written there, look at the problem 
> space, determine the set of things that we want, and then make 
> sure they're expressed appropriately.
>
> 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.
>
> 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. From here; optimisers will typically 
> inline the call
> if they determine it's an advantage to do so.
>
> 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.

No. I rather see "inline" as a hint for the backend.
DMD is peculiar with its way of inlining.

> 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]

what if the function address is took in a delegate ?
It still needs to be there, in the object matching to the CU 
where it is declared, otherwise there will be surprises, e.g 
&func in a CU and &func in another will have different addresses.