Why private methods cant be virtual?

[claptrap]

On Tuesday, 22 September 2020 at 00:46:02 UTC, Steven 
Schveighoffer wrote:
> On 9/21/20 7:52 PM, H. S. Teoh wrote:
>> On Mon, Sep 21, 2020 at 07:43:30PM -0400, Steven Schveighoffer 
>> via Digitalmars-d-learn wrote:
>> [...]
>>> No, it's not a bug. It's intentional.
>>>
>>> private and package functions are final, and we aren't going 
>>> to change
>>> that now, even if it makes sense to make them virtual.
>> [...]
>> 
>> Whoa.  But why??  What's the reasoning behind private being 
>> non-virtual?
>
> You'd have to confirm with Walter. This is a relic from D1. I 
> think it has something to do with the expectation of whether a 
> private function makes sense to override. The use case is 
> pretty narrow -- allow overriding only within the current 
> package/module. But I can see the use case being valid.
>
> However, changing it now means a slew of code becomes virtual 
> that is currently not virtual. This could be a problem for 
> existing code.
>
> If we ever got a virtual keyword, then it might be possible to 
> allow them to become virtual if you opt-in. But I don't see it 
> happening without that.

"All public and protected member functions which are non-static 
and are not templatized are virtual ***unless the compiler can 
determine that they will never be overridden***"

IE the compiler is supposed to make methods non-virtual 
automatically, it should be easy to do for private as all the 
relevant info be in the one compilation unit.

Then there's this gem from the docs..

"Functions marked as final may not be overridden in a derived 
class, unless they are also private"

So final private functions can be overriden? It seems not, but 
the sentence is definitely confusing if not just plain wrong.