[Issue 3396] Compiler accepts call of superclass abstract method with no implementation - is this intended?

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=3396

Stewart Gordon <smjg at iname.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|diagnostic                  |spec
             Status|RESOLVED                    |REOPENED
         Resolution|INVALID                     |---
           Assignee|nobody at puremagic.com        |bugzilla at digitalmars.com
            Summary|Call of abstract method not |Compiler accepts call of
                   |detected by semantic check  |superclass abstract method
                   |                            |with no implementation - is
                   |                            |this intended?

--- Comment #16 from Stewart Gordon <smjg at iname.com> ---
(In reply to yebblies from comment #6)
> could mean one of two things:
> 1. M is a pure virtual function
> 2. M provides 'base class functionality', but this is a di file so the body
> isn't present.

Whether it's a di file or not, it could potentially be either.  I'd be
surprised if this ambiguity is a deliberate design decision.  It also means
that it's impossible to tell whether super.M() is a valid call just by reading
the code.  If I were designing it, I would define a way to distinguish them,
such as requiring the extern attribute for meaning 2.

Anyhow, we need clarification of this.  At the moment there's nothing in the
spec indicating that defining "base class functionality" of an abstract method
elsewhere is meant to work.  If it is meant to work, there needs to be.  If it
isn't, it is a bug that the compiler accepts the code.  As such, I'm reopening
this as a spec issue.

--