private method in interface

[Jonathan M Davis]

On 2011-06-03 14:55, Michael Shulman wrote:
> On Fri, Jun 3, 2011 at 1:02 PM, Jonathan M Davis <jmdavisProg at 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