Consider: interface Foo { private void bar(); } class Bar : Foo { } void main() { Foo bar = new Bar; bar.bar; } This code has a link-time error. Removing "private" yields (correctly) a compile-time error. So we have a bug already :o). Adding a function void bar() {} to Bar keeps the link-time error in vigor, whether or not the function is private. Now, if we want D to allow Sutter's NVI idiom (http://www.gotw.ca/publications/mill18.htm) easily, it would need to enact the following rules: * A private method in an interface is part of that interface's table of signatures. * A class implementing a private method in an interface cannot graduate its visibility (e.g. protected or public). With these rules in place, D would support NVI very naturally. I think that's a powerful paradigm that would lead to very expressive and robust interfaces.
d-bugmail@puremagic.com wrote: > Consider: > > interface Foo > { > private void bar(); > } > > class Bar : Foo > { > } > > void main() > { > Foo bar = new Bar; > bar.bar; > } > > This code has a link-time error. Removing "private" yields (correctly) a > compile-time error. So we have a bug already :o). The error occurs because there's no implementation anywhere, so the vtable can't be completed. I'm assuming you're suggesting that this should be turned into a runtime error if no implementation is present anywhere, but this would be so much harder to update stuff once an interface is updated. I can't see any advantages of making this error runtime.
By the current D spec private functions are never virtual. I'm pretty sure that's why having a private function in an interface won't work.
(In reply to comment #1) > d-bugmail@puremagic.com wrote: > > Consider: > > > > interface Foo > > { > > private void bar(); > > } > > > > class Bar : Foo > > { > > } > > > > void main() > > { > > Foo bar = new Bar; > > bar.bar; > > } > > > > This code has a link-time error. Removing "private" yields (correctly) a > > compile-time error. So we have a bug already :o). > > The error occurs because there's no implementation anywhere, so the > vtable can't be completed. I'm assuming you're suggesting that this > should be turned into a runtime error if no implementation is present > anywhere, but this would be so much harder to update stuff once an > interface is updated. I can't see any advantages of making this error > runtime. The rest of my post clarifies my intent, which is not to make the error runtime.
(In reply to comment #2) > By the current D spec private functions are never virtual. I'm pretty sure > that's why having a private function in an interface won't work. That explains part of the odd behavior - the compiler has a conflict of interest of sorts. Now that I think of it, probably protected functions in an interface should be enough. Consider: interface Foo { protected void bar(); } class Bar : Foo { void bar() {} } void main() { Foo bar = new Bar; bar.bar; } This goes through, and is probably enough to make NVI work. There is the minor annoyance that the class Bar can graduate visibility from protected to public, but if it wants to, no language rule can stop it (e.g. Bar could expose the method under a different name). I will leave the bug opened because at a minimum the linker error should be really a compile-time error. Alternatively, private functions in interfaces could be allowed because they are technically final. Thanks all for your comments.
*** Issue 6170 has been marked as a duplicate of this issue. ***
This is intentional, as by D's compilation model the body of the function may be provided in another object file. eg. When using .di files. The original bug has been fixed by allowing final methods in interfaces.
dlang/dub pull request #2052 "Fix #2051: Running unit tests from DUB single file packages fails" was merged into master: - fd32d4d314c9052b0013aa867f24a2711c0554d0 by drug007: Fix #2051 "Running unittests from dub single file packages fails" Performing test command dub imports every source file as module to build the project excluding the main source file. But this excluding may fail and in this case dub try to import the main source file as module. Single file package building fails because the main source file does not belong to any import path. Now both the current file and the main source file paths are compared in relative form to prevent importing the main source file as module. https://github.com/dlang/dub/pull/2052