D issues are now tracked on GitHub. This Bugzilla instance remains as a read-only archive.
Issue 2894 - abstract classes sometimes allow non-abstract bodyless functions
Summary: abstract classes sometimes allow non-abstract bodyless functions
Status: RESOLVED FIXED
Alias: None
Product: D
Classification: Unclassified
Component: dmd (show other issues)
Version: D1 (retired)
Hardware: x86 Linux
: P2 normal
Assignee: No Owner
URL:
Keywords: link-failure, spec
Depends on:
Blocks:
 
Reported: 2009-04-25 02:06 UTC by Christian Kamm
Modified: 2014-04-18 09:12 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description Christian Kamm 2009-04-25 02:06:12 UTC
This compiles and links

abstract class C { void foo(); }
void main() {}

while this doesn't

interface I { void foo(); }
abstract class C : I { void foo(); }
void main() {}

with an undefined reference to `_D7abstfun1C3fooMFZv'.

Since methods in abstract classes may have bodies and being allowed to implement a member function elsewhere than the class definition is a goal (see resolution of bug 1289), the first case should also require a definition for foo. This is also what I would expect from reading the spec on abstract functions and classes.
Comment 1 Stewart Gordon 2009-04-25 08:36:00 UTC
That the first example links is understandable - because C.foo is never used, the compiler doesn't create any references to it.

That the second example fails is semi-understandable - presumably the compiler creates a vtbl for C's implementation of I, but the linker cannot resolve it because no implementation of C.foo() has been linked in.  However, it does seem that DMD could be better at DCE.

Less understandable is that this fails with the same error:
----------
abstract class C { void foo(); }
class D : C {}
void main() { }
----------

It was my understanding as well that a function in an abstract class is automatically abstract if no body is given.  But it appears now that it's the same as in a non-abstract - if the function isn't declared abstract, it references an externally-defined function.  Still, the spec probably needs to be clearer on the issue.