What does 'inline' mean?

Dukc ajieskola at gmail.com
Mon Jun 8 11:53:47 UTC 2020


On Monday, 8 June 2020 at 06:14:44 UTC, Manu wrote:
> 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]

I think this should be controlled by the visibility attributes, 
not `pragma(inline)`. If a function is `private`, there's no 
reason why the linker should see it at all. If it's `public`, it 
should be seen when linking the internal object files together, 
but not when linking a precompiled binary. `export` should always 
be visible.

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

This is what `pragma(inline)` should be for. For some extent at 
least, it also is. If you compile a simple example with `ldc2 
-O1`, it'll inline the function if you use the pragma but not 
otherwise. `ldc2 -O2` will inline it regardless and DMD will 
never do it IIRC, at least not without the `-inline` switch. I 
agree that it should.

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

Sounds like a case for mixins, either type of them. But it'd be 
better if the compiler would only ignore `pragma(inline, true)` 
if either linking externally or avoiding recursion. There's just 
no reason to ignore it otherwise. This is an implementation 
problem, not a spec problem IMO.


More information about the Digitalmars-d mailing list