private/package methods cannot be virtual

[deadalnix]

On Monday, 6 May 2013 at 18:44:07 UTC, Jonathan M Davis wrote:
> On Monday, May 06, 2013 14:19:12 Henning Pohl wrote:
>> Documentation:
>> Member functions which are private or package are never 
>> virtual,
>> and hence cannot be overridden.
>> 
>> I was about to write a bug report about this, because in my 
>> code
>> there are tons of overridden methods which actually should be
>> private/package. Can anyone tell me why this decision has been
>> made? To inline them?
>> 
>> Do I really need to write interfaces to be able to override 
>> these
>> methods?
>
> The decision was made to make member functions virtual by 
> default. As soon as
> that function was made, there had to be a choice for every 
> access level as to
> whether it would be virtual or not. public and protected 
> obviously have to be
> virtual, and in general, there's no real benefit in making 
> private virtual (and
> there's a definite permorfance cost to programs in general if 
> you do), so it's
> non-virtual. There's a bit of disagreement with regards to 
> package, but it was
> decided that it wouldn't be virtual either, as it had nothing 
> to do with
> inheritance.
>

If it is private, by definition, the compiler have all override 
available. So it can finalize automatically.