Undefined symbol for, apparently, valid code?

[Arafel via Digitalmars-d-learn]

On 07/06/2017 05:11 PM, unleashy wrote:

> 
> Maybe it was an error on my part for not declaring the function as 
> abstract? My view was that the abstract attribute on a class marks all 
> its members as virtual unless they have a body, which is how it works 
> in, say, Java.
> 
> Still, kinda odd that the linker is the one to call me out, and not the 
> compiler. Pretty unexpected.
> 

I think an "abstract" class is only one that cannot be directly 
instantiated, only through a derived class. It might be "complete", though.

This doesn't mean (and that's the confusion) that there couldn't be a 
function with a body defined in another compilation unit.

In java there are no forward declarations, so there is no ambiguity 
here: a bodyless method means an abstract method. In D a bodyless method 
can mean:

* An abstract method (to be provided by derived classes), which of 
course must then be virtual. This is indicated with the keyword "abstract".
* A method whose body is provided by some other compilation unit.

Of course, an abstract class without abstract methods isn't usually the 
intended idea... But the compiler will silently accept it and let the 
linker complain afterwards.

Again, "final by default" to me is more confusing when anything else, 
specially when it's usually "virtual by default"... and it's clearly a 
bug that it compiles after explicitly overriding!