<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 15 March 2014 18:50, Daniel Murphy <span dir="ltr"><<a href="mailto:yebbliesnospam@gmail.com" target="_blank">yebbliesnospam@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">"Walter Bright"  wrote in message news:lg0vtc$2q94$1@<u></u>digitalmars.com...<div class="">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
I find it peculiar to desire a 'final accessor'. After all,<br>
<br>
     class C {<br>
         int x;<br>
         final int getX() { return x; } <= what the heck is this function for?<br>
     }<br>
</blockquote>
<br></div>
Yeah, it's stupid, but people do it all over the place anyway.</blockquote><div><br></div><div>Religiously. They're taught to do this in books and at university, deliberately.</div><div>Seriously though, there are often reasons to put an interface in the way; you can change the implementation without affecting the interface at some later time, data can be compressed or stored in an internal format that is optimal for internal usage, or some useful properties can be implied rather than stored explicitly. Programmers (reasonably) expect they are inlined.</div>
<div><br></div><div>For instance framesPerSecond() and timeDelta() are the reciprocal of eachother, only one needs to be stored.</div><div>I also have very many instances of classes with accessors to provide user-facing access to packed internal data, which may require some minor bit-twiddling and casting to access. I don't think this is unusual, any programmer is likely to do this. empty(), length(), front(), etc are classic examples where it might not just return a variable directly. Operator overloads... >_<</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
It's a major breaking change. It'll break nearly every D program out there that uses classes.<br>
</blockquote>
<br></div>
This is nonsense.  I tried out the warning on some of my projects, and they required ZERO changes - because it's a warning!<br>
<br>
Phobos requires 37 "virtual:"s to be added - or just change the makefile to use '-wi' instead of '-w'.  Druntime needed 25.<br>
<br>
We don't even need to follow the usual 6-months per stage deprecation - We could leave it as a warning for 2 years if we wanted!<br>
<br>
Grepping for class declarations and sticking in "virtual:" is as trivial as a fix can possibly be. <br>
</blockquote></div><br></div><div class="gmail_extra">My game that I'm hacking on at the moment has only 2 affected classes. The entire game is OO. Most virtuals are introduced by interfaces.</div><div class="gmail_extra">
So with that in mind, it's not even necessarily true that projects that use classes will be affected by this if they make use of interfaces (I certainly did at Remedy, exclusively).</div><div class="gmail_extra"><br></div>
<div class="gmail_extra">Phobos is a standard library, surely it's unacceptable for phobos calls to break the optimiser? Consider std.xml for instance; 100% certain to appear in hot data crunching loops.</div><div class="gmail_extra">
What can be done about this? It can't be fixed, because that's a breaking change. Shall we document that phobos classes should be avoided or factored outside of high frequency code, and hope people read it?</div></div>