www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 5129] New: More strict 'abstract' management

reply d-bugmail puremagic.com writes:
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: -------
Oct 29 2010
next sibling parent d-bugmail puremagic.com writes:
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: -------
Oct 29 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Oct 30 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Oct 30 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Oct 30 2010
prev sibling parent d-bugmail puremagic.com writes:
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: -------
Jan 23 2012