Andrei's interface requests

[Andrei Alexandrescu]

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).

Makes sense.

> 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.

So far so good.

> 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!

Yah, but let me point out that interfaces can be also relaxed to require 
less conformance, just like you describe.

> On the contrary, interface defines a set of *virtual functions* that are 
> invokable through an instance of that interface.

It does so currently. It doesn't mean the definition can't be improved, no?

> 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).

I think this is really funny reading: 
http://www.thebestpageintheuniverse.net/c.cgi?u=puns It convinced me to 
avoid emphasizing or denying my puns :o).

Anyway, I agree with your point that uses of interface as concept may 
sometimes interfere with its uses in the traditional sense. One thing 
that comes to mind is:

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.)

> 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.
> 

I don't see enough good uses for this feature.


Andrei