<div dir="ltr">On 10 April 2013 21:09, Regan Heath <span dir="ltr"><<a href="mailto:regan@netmail.co.nz" target="_blank">regan@netmail.co.nz</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Wed, 10 Apr 2013 11:59:32 +0100, Dicebot <<a href="mailto:m.strashun@gmail.com" target="_blank">m.strashun@gmail.com</a>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Wednesday, 10 April 2013 at 10:53:26 UTC, Regan Heath wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hmm..<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
A is not final.<br>
</blockquote>
<br>
True.  But, I don't see how this matters.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
A has no internal linkage. It can be inherited from in other compilation unit.<br>
</blockquote>
<br>
False.  In this first example we are compiling A and B together (into an exe - I left that off) so the compiler has all sources and all uses of all methods of A (and B).<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
notVirt is virtual.<br>
</blockquote>
<br>
It may actually be (I don't know) but it certainly does not have to be (compiler has all sources/uses) and my impression was that it /should/ not be.<br>
<br>
R<br>
</blockquote>
<br>
If it is compiled all at once and compiled into executable binary than yes, you examples are valid and compiler _MAY_ omit virtual.<br>
</blockquote>
<br></div>
Exactly the point I was trying to make.  I wanted to establish the point at which the design problems (what D defines/intends to do) arise, vs when the implementation problems arise (DMD not doing what D intends).<div class="im">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
But<br>
a) DMD doesn't do it as far as I am aware.<br>
</blockquote>
<br></div>
Maybe, maybe not.  I have no idea.  My understanding of the design decision is that DMD will eventually do it.</blockquote><div><br></div><div style>I feel like I'm being ignored. It's NOT POSSIBLE. </div><div style>
<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
b) It is a quite uncommon and restrictive build setup.<br>
</blockquote>
<br></div>
Maybe at present.<br>
<br>
Lets assume DMD can remove virtual when presented with all sources compiled in one-shot.<br>
<br>
Lets assume it cannot if each source is compiled separately.  Is that an insurmountable problem?  A design problem?  Or, is it simply an implementation issue.  Could an obj file format be designed to allow DMD to perform the same optimisation in this case, as in the one-shot case.  My impression is that this should be solvable.<br>

<br>
So, that just leaves the library problem.  Is this also insurmountable?  A design problem?  Or, is it again an implementation issue.  Can D not mark exported library methods as virtual/non-virtual?  When user code derives from said exported class could D not perform the same optimisation for that class?  I don't know enough about compilation to answer that.  But, I can see how if the library itself manifests an object of type A - which may actually be an internal derived sub-class of A, there are clearly issues.  But, could DMD not have two separate definitions for A, and use one for objects manifested from the library, and another locally for user derived classes?  I don't know, these are all just ideas I have on the subject.  :p</blockquote>
<div><br></div><div style>That sounds overly complex and error prone. I don't believe the source of an object is actually trackable in the way required to do that.</div><div style>I can't conceive any solution of this sort is viable. And even if it were theoretically possible, when can we expect to see it implemented?</div>
<div style>It's not feasible. The _problem_ is that functions are virtual by default. It's a trivial problem to solve, however it's a major breaking change, so it will never happen.</div><div style>Hence my passing comment that spawned this whole thread, I see it as the single biggest critical mistake in D, and I'm certain it will never be changed. I've made my peace, however disappointing it is to me.</div>
</div></div></div>