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

RazvanN <razvan.nitu1305@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |razvan.nitu1305@gmail.com
         Resolution|---                         |INVALID

--- Comment #1 from RazvanN <razvan.nitu1305@gmail.com> ---
I think that this is the correct behavior. The function is defined (and therefore respects the interface contract) it's just that it does not have a body. You can provide the body in a different file.

Think about header files (.di). Those should contain compilable d code and not contain any function bodies. If this were to be fixed, then you would not be able to have any interfaces and classes in .di files.

Closing as invalid.

--

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

--- Comment #2 from alexandru.ermicioi@gmail.com ---
This is in .d file, and is completely clear that is a bug, since you can't have an unimplemented method. Only abstract methods may not have a body, since it is expected to be implemented somewhere else.

I struggle to even understand how you could implement such a method given it is a D method, not c++ one.

--

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

alexandru.ermicioi@gmail.com changed:

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

--- Comment #3 from alexandru.ermicioi@gmail.com ---
Reopening it.

--

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

--- Comment #4 from RazvanN <razvan.nitu1305@gmail.com> ---
(In reply to alexandru.ermicioi from comment #2)
> This is in .d file, and is completely clear that is a bug, since you can't have an unimplemented method. Only abstract methods may not have a body, since it is expected to be implemented somewhere else.
> 
> I struggle to even understand how you could implement such a method given it is a D method, not c++ one.

If you know the exact mangled name you can implement it in a different file

--

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

--- Comment #5 from RazvanN <razvan.nitu1305@gmail.com> ---
Also, there in the initial example you forgot to inherit from Promise.

--

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

Dennis <dkorpel@live.nl> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
                 CC|                            |dkorpel@live.nl
         Resolution|---                         |INVALID

--- Comment #6 from Dennis <dkorpel@live.nl> ---
(In reply to alexandru.ermicioi from comment #2)
> This is in .d file, and is completely clear that is a bug, since you can't have an unimplemented method. (...) I struggle to even understand how you could implement such a method given it is a D method, not c++ one.

That's just false. Separate compilation is a thing, and functions without
bodies are not limited to `.di` files (which is just a convention) or
`extern(C++)` (which is just a different ABI and mangling scheme). See:

https://dlang.org/spec/function.html#function-declarations

--

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

--- Comment #7 from alexandru.ermicioi@gmail.com ---
Well, at that point I've failed to think about separate compilation.

Seems like forward declarations are allowed anywhere.

It is still an unpleasant experience when you forget implementing a method and get mangled method name as an error from linker and not compiler.

--

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

--- Comment #8 from Dennis <dkorpel@live.nl> ---
(In reply to alexandru.ermicioi from comment #7)
> It is still an unpleasant experience when you forget implementing a method and get mangled method name as an error from linker and not compiler.

Yes, it would be great to have linkers with D demangling support.

--