Why private methods cant be virtual?

Steven Schveighoffer schveiguy at gmail.com
Tue Sep 22 00:46:02 UTC 2020


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.

If you do a search on the general forum, you will find a few 
conversations about this in the way past. It's been discussed, but never 
changed.

-Steve


More information about the Digitalmars-d-learn mailing list