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



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



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





 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






 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






 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



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