<div dir="ltr"><div dir="ltr">On Fri, Jun 12, 2020 at 11:51 AM Manu <<a href="mailto:turkeyman@gmail.com">turkeyman@gmail.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">On Fri, Jun 12, 2020 at 8:20 AM Walter Bright via Digitalmars-d <<a href="mailto:digitalmars-d@puremagic.com" target="_blank">digitalmars-d@puremagic.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 6/11/2020 8:42 AM, kinke wrote:<br>
> My interest in this wasn't triggered by wanting to enforce particular functions <br>
> to be emitted into each referencing CU, but by<br>
> a) the current emission scheme requiring LTO in order to inline suited little <br>
> templated functions when compiling static libs in one go,<br>
> b) being able to use linkonce_odr instead of weak_odr linkage for template <br>
> stuff, meaning potentially less work for the linker, and potentially quite a bit <br>
> less work for the optimizer. Compiling an optimized dub (a single object file) <br>
> with LDC using -linkonce-templates reduces the total compile+optimize times by <br>
> roughly 25%, simply because LLVM inlines most little template stuff and can then <br>
> discard the unused linkonce_odr functions early in the process, without <br>
> uselessly optimizing them to death (as it currently cannot discard it, as other <br>
> libraries/objects might depend on some template instances as mentioned earlier).<br>
<br>
A library consists of two parts:<br>
<br>
1. the "header" file<br>
2. the binary to link with, which may be absent<br>
<br>
Take some care in what goes in 1, what goes in 2, and you'll be fine.<br>
<br>
For example, consider core.checkedint. The functions in it are all templates so <br>
that they can be used with -betterC which doesn't link with druntime. It's a <br>
classic "header only" library. It works fine.<br></blockquote><div><br></div><div>We're not talking about templates. </div></div></div></blockquote><div><br></div><div>This is another one of those cases is really bizarre resistance to what seems like a blindingly obvious thing.</div><div>Can you please explain why you feel opposed to this, and why our existing solution, which is 'weird' by all accounts, and satisfies ZERO of the goals assigned to inline is preferable?</div><div>The existing implementation is inline is a COMPLETELY useless thing. If you can't see where I'm coming from in this thread, then I suggest we remove it completely.</div><div>It's existence solves zero problems, and does actual damage to D by existing, because people try it and find that it's broken, and then they're confused and/or lose a little confidence in D.</div><div>I mean that seriously; if you deny there's a problem and refuse to fix this, then I seriously encourage you to deprecate and remove pragma(inline) from the language. It's worse than nothing.</div></div></div>