What does 'inline' mean?

Manu turkeyman at gmail.com
Mon Jun 8 06:14:44 UTC 2020


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.

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]

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]

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]

I think these are the 3 broad categories of behaviour I have ever wanted
control over.
Personally speaking, I am perfectly happy with C/C++'s choice to conflate 1
& 2 into a thing called `inline`, and that's what I want the word 'inline'
to do at an absolute minimum.
The 3rd thing I would term something like `force inline` or perhaps
pragma(inline, force).

D's inline today doesn't do any of those things. It doesn't implement a
mechanic that I have ever wanted or known a use for.

Are there non-theoretical use cases I've missed that people have
encountered?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20200608/0f98b957/attachment.htm>


More information about the Digitalmars-d mailing list