Broken?

[Steven Schveighoffer]

On Wed, 12 Mar 2014 09:15:14 -0400, Michel Fortin  
<michel.fortin at michelf.ca> wrote:

> On 2014-03-12 12:48:59 +0000, "Steven Schveighoffer"  
> <schveiguy at yahoo.com> said:
>
>> On Wed, 12 Mar 2014 08:32:14 -0400, Michel Fortin   
>> <michel.fortin at michelf.ca> wrote:
>>
>>> I'll add another argument to the mix.
>>>  Currently, you can't have private/package functions that are  
>>> virtual,  contrary to what TDPL says.
>>>  To make things coherent we could change private function so they  
>>> become  virtual by default. You might be able to see the problem with  
>>> this  option: making private function virtual by default is likely to  
>>> add many  performance regressions in existing code, silently.
>>  Private virtual functions make 0 sense. A private function cannot be   
>> accessed by a derived class. Who gets to access a overriden virtual   
>> function? The base class only? If I'm writing a function, I certainly   
>> should be able to access it, no? Even if you want to restrict my  
>> access,  you cannot, I'm in control of that code!
>
> You're mixing C++ private with D private. Private just means the symbol  
> is only accessible within the same module. You can have a whole class  
> hierarchy in a module if you want, and thus could override private  
> functions assuming they could be virtual.

OK, I can see that being useful. You are right, I was thinking C++ private.

So essentially, a virtual private function can only be overridden in  
classes defined in the same module. What happens when you do it in a  
separate module, an error? What if you want to define that function name,  
but it's taken by the base class, what happens?

-Steve