Broken?

[Steven Schveighoffer]

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

> On 2014-03-12 03:04:38 +0000, Manu <turkeyman at gmail.com> said:
>
>> virtual-by-default is incompatible with optimisation, and it's reliable  
>> to
>> assume that anybody who doesn't explicitly care about this will stick  
>> with
>> the default, which means many potentially useful libraries may be
>> eliminated for use by many customers.
>
> 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!

Package, I'm less concerned about. You can make that virtual, I don't ever  
use package functions.

-Steve