What does 'inline' mean?

[Walter Bright]

On 6/9/2020 7:21 AM, Manu wrote:
>     The C/C++ inline semantics revolve around the mechanics of .h files because it
>     doesn't have modules. These reasons are irrelevant for D.
> 
> 
> That's completely incorrect. It's 100% as relevant for D as it is for C++ for 
> exactly the same reasons.
> You'll need to support your claim.

Um, because of the way #include works, C++ sees the same inline function 
definition over and over again, and has no way of knowing if any other files see 
the same definition or not, or if they have the same implementation or not. The 
semantics are carefully crafted around the reality that there may be multiple 
copies of the inline function definition in compilation units that have no clue 
of the existence of each other. The internal linkage thing is there to support 
more primitive linkers that have no support for COMDAT sections.

This is completely different from a module system. Also, D relies heavily on 
linker support for COMDATs.


> Because in this category of use case, inlining is a concept related to native 
> languages with binary linkage, and not really anything to do with the language 
> specifically.

Given all the verbiage about inlines in the C++ spec, it does have to do with 
the language specifically.


> Any other result is just 'weird', and while it might be workable, it's just 
> asking for trouble. (1 redundant copy in the owning CU despite being 
> un-referenced MIGHT be link-stripped if the surrounding tooling all works as we 
> hope... but it also might not, as I have demonstrated on multiple occasions)
> There's just no reason to invite this problem... and no advantage.
> 
>      > I also want copies to appear locally when it is referenced; inline functions
>      > should NOT require that you link something to get the code... that's not
>     inline
>      > at all.
> 
>     Why? What problem are you solving?
> 
> 
> Literally inline function calling. No-link libs are a really common and 
> extremely useful thing.

At last! You say why! We have that in D with template functions. You get N 
instantiations. But they all have COMDAT linkage, which means only 1 winds up in 
the executable instead of N.


>     I know I'm being boring, but why is it important? Also, check out -gc-sections:
> 
>     https://gcc.gnu.org/onlinedocs/gnat_ugn/Compilation-options.html
> 
>     Which is a general solution, not a kludge.
> 
> 
> I guess my key issue is that I have complained before because I have experienced 
> multiple counts of the link stripping not working like you say. There is no 
> reason to invite that problem; we can trivially eliminate the problem at the 
> source. I don't care if it's fixable, I don't want the problem to exist. NOBODY 
> wants to be tasked to solve awkward build ecosystem issues... we already have a 
> working build ecosystem, and this D thing is making it harder than it already 
> is. That's a really bad thing, and I would entertain excuses for this if not for 
> the fact that it's trivially avoidable. We do not need to waste anybodies time 
> this way; we won't win any friends by wasting their time with problems they HATE 
> to have.

If gc-sections isn't working, perhaps there's something else going on. Did you 
check with the linker support people? gc-sections has been around at least 20 
years with gcc. If it fundamentally didn't work somebody would have fixed it by now.

It also may not work with your C++ compiler because it is NOT emitting the 
functions each into its own section. DMD *does* put each and every function into 
its own section, so that gc-sections will work.

I.e. C++ has workarounds for bugs it its own implementation, and those 
workarounds are not features.


> The secondary issue is, I want my binaries to contain what I put in there, and 
> not what I don't. Rogue symbols that I specified shouldn't exist only bloat the 
> binary, invite possibility of link collision, and raise the probability of the 
> issues I mentioned above.

But you're happy with (and require) N useless redundant copies of inline functions.


> I suggest, the default should model the common case, and the rare niche case can 
> be the 3rd 'force' state by explicit request.

The upcoming case is pragma(inline,true) (in my PR) is that the compiler 
attempts to inline them regardless of the -inline switch, and lists an 
informational warning (-wi) if they can't be inlined.


> This isn't about optimisation, it's about controlling the output of the 
> compiler. Taking that control away and forcing us to try and reproduce that 
> expected functionality with external tooling within a deeply complex build 
> ecosystem is wasting our valuable time.

C++'s inline semantics are rooted in accommodation for:

1. .h files rather than modules
2. object file formats that don't support COMDATs
3. linkers that don't support COMDATs

It's a collection of hacks, not features. D is free'd from those constraints.