Why private methods cant be virtual?
clap at trap.com
Tue Sep 22 09:00:22 UTC 2020
On Tuesday, 22 September 2020 at 00:46:02 UTC, Steven
> 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
> 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.
More information about the Digitalmars-d-learn