private/package methods cannot be virtual

[Jonathan M Davis]

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.

There's actually quite a bit of disagreement on whether member functions 
should be virtual by default (in particular, the guys working at companies 
which need high performance really don't like it), but at least for the 
moment, that's the way it is. And in order to make private or package 
functions virtual, we'd need a way to do so explicitly, which we don't 
currently have.

I'm considering creating a DIP on the matter, but I think that I'm going to 
wait until some of the current discussions die off; otherwise it wouldn't get 
the attention that it deserves (the rvalue discussion in particular is likely 
to be quite large).

- Jonathan M Davis