private method in interface

[Michael Shulman]

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 <jmdavisProg at gmx.com> wrote:
> 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
>