True, but it will be explicit in the derived class code:
No 'override', no function that is overridden.
However, if a programmer expects it to override, there could be
an issue. Imagine a novice D programmer who is not used to using
"override" and looks at at the following code:
class Base {
private:
void test() {}
}
class Derived: Base {
private:
void test() {}
}
He/she would assume (as I did) that Derived.test virtually
overrides Base.test because there's clearly no "final" attribute
on Base.test. This subtle quirk could cause (as it did in my
code) somewhat subtle and very frustrating bugs. It might be good
to create a warning in this situation, then have a keyword that
tells the compiler, "Yes, I really did mean to redefine a
non-virtual function."
