Thread overview
[Issue 5129] New: More strict 'abstract' management
Oct 29, 2010
nfxjfg@gmail.com
Oct 30, 2010
Stewart Gordon
Oct 30, 2010
nfxjfg@gmail.com
Jan 24, 2012
Walter Bright
October 29, 2010
http://d.puremagic.com/issues/show_bug.cgi?id=5129

           Summary: More strict 'abstract' management
           Product: D
           Version: D2
          Platform: x86
        OS/Version: Windows
            Status: NEW
          Keywords: diagnostic
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: nobody@puremagic.com
        ReportedBy: bearophile_hugs@eml.cc


--- Comment #0 from bearophile_hugs@eml.cc 2010-10-29 05:10:03 PDT ---
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

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
October 29, 2010
http://d.puremagic.com/issues/show_bug.cgi?id=5129


nfxjfg@gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nfxjfg@gmail.com


--- Comment #1 from nfxjfg@gmail.com 2010-10-29 11:05:45 PDT ---
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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
October 30, 2010
http://d.puremagic.com/issues/show_bug.cgi?id=5129


Stewart Gordon <smjg@iname.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|diagnostic                  |link-failure, spec
                 CC|                            |smjg@iname.com


--- Comment #2 from Stewart Gordon <smjg@iname.com> 2010-10-30 07:18:19 PDT ---
(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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
October 30, 2010
http://d.puremagic.com/issues/show_bug.cgi?id=5129



--- Comment #3 from nfxjfg@gmail.com 2010-10-30 14:22:28 PDT ---
(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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
October 30, 2010
http://d.puremagic.com/issues/show_bug.cgi?id=5129



--- Comment #4 from bearophile_hugs@eml.cc 2010-10-30 14:59:30 PDT ---
(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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
January 24, 2012
http://d.puremagic.com/issues/show_bug.cgi?id=5129


Walter Bright <bugzilla@digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |bugzilla@digitalmars.com
         Resolution|                            |INVALID


--- Comment #5 from Walter Bright <bugzilla@digitalmars.com> 2012-01-23 23:46:05 PST ---
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".

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------