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

Denis Shelomovskij <verylonglogin.reg@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |verylonglogin.reg@gmail.com
           Hardware|x86                         |All
         Resolution|---                         |INVALID
                 OS|Windows                     |All

--- Comment #3 from Denis Shelomovskij <verylonglogin.reg@gmail.com> ---
This is a documented and intended behavior. According to [1]:
> Functions declared as abstract can still have function bodies. This is so that even though they must be overridden, they can still provide ‘base class functionality.’

It also maches C++ behavior with respect to pure virtual functions.

An enhancement request to change it may be opened but this bug is invalid.

[1] http://dlang.org/attribute.html#abstract

--

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

Stewart Gordon <smjg@iname.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|INVALID                     |---

--- Comment #4 from Stewart Gordon <smjg@iname.com> ---
(In reply to Denis Shelomovskij from comment #3)
> This is a documented and intended behavior. According to [1]:
>> Functions declared as abstract can still have function bodies.

But A.M has no function body.  So what's the relevance?

>> This is so that even though they must be overridden, they can still provide ‘base class functionality.’

But no base class functionality has been provided.  As such, the compiler cannot resolve the call to super.M and therefore should error.

> It also maches C++ behavior with respect to pure virtual functions.

What exactly does the C++ standard say about this?

That said, is C++ behaviour relevant?  D is not C++.

--

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

yebblies <yebblies@gmail.com> changed:

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

--- Comment #5 from yebblies <yebblies@gmail.com> ---
*** Issue 13278 has been marked as a duplicate of this issue. ***

--

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

yebblies <yebblies@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
                 CC|                            |yebblies@gmail.com
         Resolution|---                         |INVALID

--- Comment #6 from yebblies <yebblies@gmail.com> ---
This code:

abstract class A
{
   abstract void M();
}

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.

The compiler makes the conservative assumption 2, because it has no way to tell which was intended.

A quick test makes it look like additionally marking the base class function with @disable makes it impossible to call without breaking inheritance.

--

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

--- Comment #7 from Denis Shelomovskij <verylonglogin.reg@gmail.com> ---
(In reply to yebblies from comment #6)
> This code:
> 
> abstract class A
> {
>    abstract void M();
> }
> 
> 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.

You misuse terminology. "pure virtual function" is a C++ term which means "this function should be overriden to be able to instantiate class". There is no term for function that doesn't provide base class functionality. So D's 'abstract' means exactly what C++'s '=0' postfix does marking function "pure virtual" in contrast to e.g. C#'s 'abstract'.

--

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

--- Comment #8 from yebblies <yebblies@gmail.com> ---
(In reply to Denis Shelomovskij from comment #7)
> (In reply to yebblies from comment #6)
> > This code:
> > 
> > abstract class A
> > {
> >    abstract void M();
> > }
> > 
> > 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.
> 
> You misuse terminology. "pure virtual function" is a C++ term which means "this function should be overriden to be able to instantiate class". There is no term for function that doesn't provide base class functionality. So D's 'abstract' means exactly what C++'s '=0' postfix does marking function "pure virtual" in contrast to e.g. C#'s 'abstract'.

I figured people would understand what I meant.  1) is a function that has no implementation.

--

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

--- Comment #9 from Orvid King <blah38621@gmail.com> ---
Isn't it still reasonable for DMD to at least catch this error at compile-time rather than link-time if the module containing class A was passed on the command line, and thus is one of those being compiled, and not an interface?

--

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

--- Comment #10 from yebblies <yebblies@gmail.com> ---
(In reply to Orvid King from comment #9)
> Isn't it still reasonable for DMD to at least catch this error at
> compile-time
> rather than link-time if the module containing class A was passed on the
> command line, and thus is one of those being compiled, and not an interface?

The compiler cannot tell the difference between d files and di files...  And technically you're allowed to put the implementation in a library, implement it in asm, etc

--

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

--- Comment #11 from Stewart Gordon <smjg@iname.com> ---
(In reply to Orvid King from comment #9)
> Isn't it still reasonable for DMD to at least catch this error at
> compile-time
> rather than link-time if the module containing class A was passed on the
> command line, and thus is one of those being compiled, and not an interface?

This would break tools such as bud.

(In reply to yebblies from comment #10)
> 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?

--

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

--- Comment #12 from Stewart Gordon <smjg@iname.com> ---
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?

--