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