Andrei's interface requests

[Yigal Chripun]

On 04/04/2009 17:41, Denis Koroskin wrote:
> I'm not sure I understand everything you intend so lets clear things a
> little.
>
> I agree there should be a way to enforce struct to implement some..
> contract.
> But I believe you took a wrong way by using pseudo-interface inheritance.
>
> First of all, it's called Concept in C++0x. I suggest to use the same
> name in D, too. (Yes, that's one more keyword, but this is just a
> discussion, right, and you didn't listen all my arguments yet).
>
> concept Range(T)
> {
> bool empty;
> T value;
> void next();
> }
>
> I don't think "void next;" is okay, besides, it's always a function
> anyway! On the other side, I can image an infinite range that returns
> constant values and next is a do nothing function, but still you can't
> have a member of type void.
>
> Concept is different from interface. Concept says that if typeof(r)
> satisfies a Range concept, then the following syntax is allowed:
>
> bool e = r.empty;
> T v = r.value;
> r.next();
>
> But it doesn't say "how". r.empty may be a property, a (static) member,
> or even an enum. And that's exactly what's needed for Range definition!
>
> On the contrary, interface defines a set of *virtual functions* that are
> invokable through an instance of that interface. That's why I don't
> support an idea of the following:
>
> interface Foo
> {
> this(int i);
> typedef Bar;
> }
>
> Foo foo = new Foo(42); // huh?
> Foo.Bar x; //what's x.typeof?
>
> BTW, why is(typeof(x)) is alowed but typeof(x) is not? I quite don't
> like x.typeof
>
> Surely, you'll disallow both syntaxes, but this gets messy. Some of
> functions are callable through interface and some are only callable
> through a class that implements that interface!
> Once again, I state that you you mistakenly mix two different concepts
> (pun is not inteded).
>
> concept Foo
> {
> int(int i);
> typedef Bar; // fine
> }
>
> Second, I believe structs *can* safely implement interfaces (hello,
> Weed!). They still shouldn't support inheritance, but *interface*
> inheritance:
>
> interface Foo
> {
> int bar();
> }
>
> struct FooImpl : Foo
> {
> int bar()
> {
> return 42;
> }
> }
>
> int acceptsFoo(Foo f)
> {
> return f.bar();
> }
>
> FooImpl fooImpl;
> acceptsFoo(fooImpl); // yes!
>
> They'll get an implicit vtbl ptr, and since they don't support struct
> inheritance, no slicing is possible.
>

What you define is Concets *in C++* and interface *in Java*.
D doesn't have to use the same definitions.
D interfaces can represent abstract types. for example, say we have this 
interface:

interface I {
   this(int i);
   alias A;
   void funcA();
   final void funcB();
}

struct A : I {...}
class B : I {...}

why not make both A and B do exactly the same with I? meaning both 
inherit polymorphically funcA (it is in the virtual table for *both*) 
and statically at compile-time the compile time symbols like the alias A 
above.
IMO, this is more consistent. as you said above, there's nothing to 
prevent polymorphic struct inheritance of interfaces since it doesn't 
introduce the slicing problem.

regarding duct-typing: C++ needs this for compatibility with existing 
code. Why do you think that D needs to do the same choice? wouldn't it 
be more consistent if D would not provide two different semantics sets 
one for compile-time and one for run-time?
D will provide things like Ranges as interfaces in the stdlib, and any 
type that supports this interface should specify that.

from Andrei's post:

> interface Interface { void foo(); }
> void foo(T : Interface)() { ... }
> class C { void foo(); }
>
> C does not explicitly declare abiding to Interface. However, structurally it does. Should foo be called? If interface is meant for binary binding, no. If interface is meant for concept checking, maybe. (The notion of "auto concept" in C++ is akin to this. There is currently a discussion on the C++ standardization mailing list on whether most concepts should be "auto" or not.)

in the above case, I think I prefer the binary binding option.