https://issues.dlang.org/show_bug.cgi?id=19570
--- Comment #9 from Manu <[email protected]> --- (In reply to Walter Bright from comment #8) > (In reply to Manu from comment #7) > > - emit a copy of the function to each CU it's called from > > But then it's going to be doing code gen for each of them over and over. Sure. inline functions are usually very short. Also, most D applications only have one CU. > > - not emit the function to the CU it's declared (unless it's called, as > > above) > > - mark the function with 'internal' linkage (what C++ calls 'static') so > > it's not in the object's exported symbol table. > > So what if it's in the symbol table? Multiple modules with the same symbol will have link collisions. It could be weak, but then you're still inviting 3rd party code to link against it, which is at odds with it's inline-ness. > > - symbol is not externally linkable > > Why not? Because every CU may have its own internal copy. > > - symbols referenced by an inline function that's never called must NOT > > cause a link error under any circumstances > > This is a linker problem - the linker is supposed to remove unreferenced > functions. It would be extremely simpler for the problem not to exist at all, and more compatible with existing binary ecosystems without unexpected errors or edge cases. --
