<div class="gmail_quote">On 11 March 2012 18:45, Artur Skawina <span dir="ltr"><<a href="mailto:art.08.09@gmail.com">art.08.09@gmail.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Other than that, there is devirtualization - D does not have 'virtual'; the compiler<br>
can still do it and even inline the virtual methods, but it needs to know that<br>
nothing overrides the functions - impossible w/o WPO for public non-final classes. [1]<br></blockquote><div><br></div><div>Oh don't get me started! (...oops, too late!)</div><div><br></div><div>This is my single greatest complaint about D, and if I were to adopt D professionally, I would almost certainly fork the language and fix this.</div>
<div>virtual-by-default seems like the single biggest and most harmful <u>mistake</u> in the whole language.</div><div>Defaulting a feature that introduces very costly damage that ONLY a WPO pass can possibly un-do can only be described as insanity.</div>
<div>Choosing to do this intentionally... does DMD have a powerful WPO? >_<</div><div><br></div><div>I genuinely fear for this decision. Junior programmers will write really slow code unknowingly, and it's too easy for anyone to simply forget to declare 'final'. Seniors will spend god only knows how much time (late nights?) trawling through the codebase verifying non-virtuals, and marking them final, time you probably can't afford when crunching to ship a product.</div>
<div>Add to that the fact that <i>validating</i> a method is not overridden anywhere is NOT a trivial task. Being able to do this with confidence will be tedious and waste unimaginable amounts of time and frustration... and why? What was the harm in explicit virtual? I expect explicit 'final' will surely overwhelm virtuals in number too when considering keyword clutter (trivial accessors, properties, etc make up the majority of methods) :/</div>
<div><br></div><div>If I were evaluating D to use commercially, this would be the biggest red flag to consider. The time/efficiency costs could potentially be very high.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im">> My understanding is that templates depends on .d/.di files being present during compilation? So why doesn't D do inlining the same way? If I declare some inline function in a .d/.di file, surely it should be capable of inlining?<br>

> C/C++ can't inline something from a foreign object either without a definition in a header...<br>
<br>
</div>It's the same for D, I just don't think *.di files should be necessary for _internal_<br>
cross-module interfaces, or when the full source is available anyway.<br>
Currently, cross-module inlining is a problem for GDC, but even when that's fixed,<br>
WPO will help things like devirtualization or changing calling conventions (gcc does<br>
it already, but i don't know if it clones non-local functions just for this, when not<br>
in WPO mode).<br></blockquote><div><br></div><div>So assuming that most libraries will be closed source, what's the implication here for inlines and tempaltes long term? It sounds no different than .h files.</div><div>
Is there a plan to be able to store that metadata inside lib/object files somehow? (I assume not, if there was, why need .di files at all)</div></div>