The bug report appears to already exist: http://d.puremagic.com/issues/show_bug.cgi?id=3258
On Fri, Jun 3, 2011 at 3:07 PM, Jonathan M Davis <jmdavisp...@gmx.com> wrote: > On 2011-06-03 14:55, Michael Shulman wrote: >> On Fri, Jun 3, 2011 at 1:02 PM, Jonathan M Davis <jmdavisp...@gmx.com> > wrote: >> > And if you don't know about NVI, having a >> > virtual private function is just plain weird. >> >> Well, it makes perfect sense to me, once given that in D, 'private' >> allows access from anywhere in the same module, rather than only in >> the defining class. I agree that it's weird and surprising in C++. >> >> Are 'package' qualified functions also non-virtual? The documentation >> http://d-programming-language.org/function.html#virtual-functions >> says that "all non-static non-private non-template member functions >> are virtual", but I get the same sort of linker errors with 'package' >> functions that I do with 'private' ones, even with code that's all in one >> module. > > I would expect package to be virtual, but Walter could have implemented it as > non-virtual on the theory that if you wanted it to be overridden, it would be > protected (which would be the normal thing to do when you intend to have a > derived class override a member function). I'd suggest opening a bug report. > It wouldn't hurt my feelings any if private and package were both always non- > virtual, but TDPL says that they're both virtual, and the online docs says > that package is virtual, so either the compiler needs to be fixed or TDPL and > the docs need to be changed. Regardless, I would have hoped that you'd get an > error at compile time about overriding a non-virtual function if package is > non-virtual, so at minimum, the error message needs to be improved. So, open a > bug report on it, and Walter can make whatever changes are appropriate. > > - Jonathan M Davis >