Broken?

[Szymon Gatner]

On Wednesday, 12 March 2014 at 12:48:58 UTC, Steven Schveighoffer 
wrote:
> 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

Private virtual functions actually make a LOT of sense in C++. 
Ever heard of NVI? It is actually good design practice to make 
class virtuals private in many cases and relay on Template Method 
pattern. Even Andrei advices that in C++ Coding Standards.