Broken?

[Michel Fortin]

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.


-- 
Michel Fortin
michel.fortin at michelf.ca
http://michelf.ca