• simendsjo (30/30) Sep 23 2013 I just came across a problem where I either has a cyclic
• Jonathan M Davis (13/30) Sep 24 2013 Only public and protected are virtual. private and package are never vir...
• simendsjo (3/44) Sep 24 2013 Ok, thanks. I'll fix it some other way.

"simendsjo" <simendsjo gmail.com> writes:

I just came across a problem where I either has a cyclic 
dependency, pass around three delegates, implement an interface 
or somehow hack some communication between two modules.

A simple way would be to add an interface, but interfaces require 
implementations to be public. The methods should be package 
protected though.

It would have been nice if the implementation for an interface 
wouldn't have to be more visible than the interface itself.

If an interface is "package", it cannot escape that package, so 
why would the implementation required to be public? The same goes 
for "private".

Should I add an enhancement request for this, or does it have 
problems I'm not seeing?

---

module b;

package interface I {
     void doit();
}

void f(I i) { i.doit(); }

---

module a;
import b;

class C : I {  // Error: class a.C interface function 'void 
doit()' is not implemented
     package void doit() {}
}

void main() {
     auto c = new C;
     f(c);
}

Jonathan M Davis <jmdavisProg gmx.com> writes:

On Tuesday, September 24, 2013 08:54:42 simendsjo wrote:
 I just came across a problem where I either has a cyclic
 dependency, pass around three delegates, implement an interface
 or somehow hack some communication between two modules.
 
 A simple way would be to add an interface, but interfaces require
 implementations to be public. The methods should be package
 protected though.
 
 It would have been nice if the implementation for an interface
 wouldn't have to be more visible than the interface itself.
 
 If an interface is "package", it cannot escape that package, so
 why would the implementation required to be public? The same goes
 for "private".
 
 Should I add an enhancement request for this, or does it have
 problems I'm not seeing?

Only public and protected are virtual. private and package are never virtual. 
This is by design. As such, it is impossible for an interface to be anything 
but public or protected and actually work.

There has been some discussion of making it so that non-virtual is the 
default, in which case, we'd have the virtual keyword, and it would be 
required to make a function virtual (similar to C++). If we ever actually go 
that route, then it may become possible to make package and private functions 
virtual (or it may not - that will depend on what's decided at that point), 
but it's definitely not going to happen if we don't go that route.

So, if you want to use interfaces, you need to be using public or protected to 
implement them. package and private are not an option.

- Jonathan M Davis

"simendsjo" <simendsjo gmail.com> writes:

On Tuesday, 24 September 2013 at 07:08:24 UTC, Jonathan M Davis 
wrote:
 On Tuesday, September 24, 2013 08:54:42 simendsjo wrote:
 I just came across a problem where I either has a cyclic
 dependency, pass around three delegates, implement an interface
 or somehow hack some communication between two modules.
 
 A simple way would be to add an interface, but interfaces 
 require
 implementations to be public. The methods should be package
 protected though.
 
 It would have been nice if the implementation for an interface
 wouldn't have to be more visible than the interface itself.
 
 If an interface is "package", it cannot escape that package, so
 why would the implementation required to be public? The same 
 goes
 for "private".
 
 Should I add an enhancement request for this, or does it have
 problems I'm not seeing?

 Only public and protected are virtual. private and package are 
 never virtual.
 This is by design. As such, it is impossible for an interface 
 to be anything
 but public or protected and actually work.

 There has been some discussion of making it so that non-virtual 
 is the
 default, in which case, we'd have the virtual keyword, and it 
 would be
 required to make a function virtual (similar to C++). If we 
 ever actually go
 that route, then it may become possible to make package and 
 private functions
 virtual (or it may not - that will depend on what's decided at 
 that point),
 but it's definitely not going to happen if we don't go that 
 route.

 So, if you want to use interfaces, you need to be using public 
 or protected to
 implement them. package and private are not an option.

 - Jonathan M Davis

Ok, thanks. I'll fix it some other way.