[Issue 3396] Call of abstract method not detected by semantic check (page 2)

https://issues.dlang.org/show_bug.cgi?id=3396 --- Comment #13 from yebblies <yebblies@gmail.com> --- (In reply to Stewart Gordon from comment #11) > > The compiler cannot tell the difference between d files and di files... > > How do you mean, the compiler can't know the filename extension of the file passed into it? It could, but it doesn't, and it shouldn't. d files and di files are the same thing to the compiler. --

https://issues.dlang.org/show_bug.cgi?id=3396 --- Comment #14 from yebblies <yebblies@gmail.com> --- (In reply to Stewart Gordon from comment #12) > http://dlang.org/function.html > "Functions without bodies: > > int foo(); > > that are not declared as abstract are expected to have their implementations elsewhere, and that implementation will be provided at the link step." > > Where does the spec indicate that functions that _are_ declared as abstract can also have their implementations elsewhere? Where does it say that they can't? --

https://issues.dlang.org/show_bug.cgi?id=3396 --- Comment #15 from Stewart Gordon <smjg@iname.com> --- (In reply to yebblies from comment #14) > Where does it say that they can't? If such code is legal, the spec needs to explain its semantics somewhere. --

August 12, 2014

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

Posted by Stewart Gordon

Permalink

Stewart Gordon

Permalink

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

Stewart Gordon <smjg@iname.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|diagnostic                  |spec
             Status|RESOLVED                    |REOPENED
         Resolution|INVALID                     |---
           Assignee|nobody@puremagic.com        |bugzilla@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@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.

--

https://issues.dlang.org/show_bug.cgi?id=3396 Dlang Bot <dlang-bot@dlang.rocks> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |pull --- Comment #17 from Dlang Bot <dlang-bot@dlang.rocks> --- @SixthDot created dlang/dmd pull request #15652 "fix issue 3396 - call to unimplemented abstract method lead to linkin…" fixing this issue: - fix issue 3396 - call to unimplemented abstract method lead to linking error https://github.com/dlang/dmd/pull/15652 --

https://issues.dlang.org/show_bug.cgi?id=3396 Dlang Bot <dlang-bot@dlang.rocks> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution|--- |FIXED --- Comment #18 from Dlang Bot <dlang-bot@dlang.rocks> --- dlang/dmd pull request #15652 "fix issue 3396 - call to unimplemented abstract method lead to linkin…" was merged into master: - 275ce6d25826599cce5538161831cfd47fb038ae by Basile Burg: fix issue 3396 - call to unimplemented abstract method lead to linking error https://github.com/dlang/dmd/pull/15652 --

Forums