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.
