Bug 5129 – More strict 'abstract' management

DMD 2.050beta compiles this, then it fails at linking time: abstract class A { public void foo(); } class B : A {} void main() {} What I expect: A compile-time error generated by the compiler, something like: error(4): class 'B' is not abstract, yet it doesn't implement abstract method 'foo' of class 'A' it inherits from. See also bug 2946

Declarations like "foo" in your example work roughly like they do in C++ (except that it makes less sense in D). Just look at how object.di works: it's full of bodyless non-abstract methods. All dmd can do is to cause a linking error. Even though it's an obscure feature with questionable value.

(In reply to comment #1) > Declarations like "foo" in your example work roughly like they do in C++ > (except that it makes less sense in D). Just look at how object.di works: it's > full of bodyless non-abstract methods. It was once the case that bodyless functions are implicitly abstract. This was partly changed http://www.digitalmars.com/d/1.0/changelog1.html#new080 but I don't know what change was made to the spec to reflect this. I think the underlying problem is that there's no mandatory explicit notation for externally defined functions. > All dmd can do is to cause a linking error. Even though it's an obscure feature > with questionable value. Not necessarily - it could realise that classes A and B and never used and so generate no code for them.

(In reply to comment #2) > It was once the case that bodyless functions are implicitly abstract. This was > partly changed > http://www.digitalmars.com/d/1.0/changelog1.html#new080 > but I don't know what change was made to the spec to reflect this. Not sure, but I remember one case (far post dmd 1.000) where dmd silently accepted a function without body as member of an abstract class, while it caused linker errors on LDC.

(In reply to comment #3) > Not sure, but I remember one case (far post dmd 1.000) where dmd silently > accepted a function without body as member of an abstract class, while it > caused linker errors on LDC. Very often when things aren't defined & enforced in a tidy way, sooner or later you will have some troubles. Compared to the Java compiler DMD is incredibly sloppy, and this will probably cause some troubles later.

This is not a bug, as in another module there could be a class C that derives from B and implements foo(). As documented, D accepts non-abstract functions with no body declared as: void foo(); with the idea that the user will be supplying a body somewhere else - perhaps even a C function or an assembler one. It's another way of doing encapsulation by having an opaque implementation. In fact, it's used by the TypeInfo's. I object to calling this "incredibly sloppy".

(In reply to comment #5) > This is not a bug, as in another module there could be a class C that derives > from B and implements foo(). > > As documented, D accepts non-abstract functions with no body declared as: > > void foo(); > > with the idea that the user will be supplying a body somewhere else - perhaps > even a C function or an assembler one. It's another way of doing encapsulation > by having an opaque implementation. In fact, it's used by the TypeInfo's. > > I object to calling this "incredibly sloppy". I didn't remember this, thank you for your answer. Despite having some usages, I think accepting this behavior _on default_ is going to bite most normal programmers. I think in most cases this is a bug in the code that the compiler is not finding at compile-time. So maybe in the uncommon cases where the programmer wants this, the usage some kind of annotation (extern ? @elsewhere ? etc) is better.

*** Issue 11464 has been marked as a duplicate of this issue. ***