concepts and interfaces

[Reiner Pope]

I would imagine that complete compile-time introspection information 
would make a lot of this much easier in D -- a lot of it could be 
implemented in the libraries.

> - why does conformance to an interface have to be specified explicitly (as in class C implements interface I)? Why not do post-hoc checking as with concepts/templates?
> Using an object via an interface implies two things - the compiler has to check whether the objects class actually implements all methods required by the interface and the object reference has to be manipulated in such a way that when using it when assigned to an interface reference the right method calls are done. If we assume that all casts from an object to an interface reference are visible at compile time both of these could be done *at the point of the cast* (equivalent to the way type checking is done for template instantiation).
I agree. This idea (often called structural typing, as opposed to 
nominative typing) is often much more flexible. There can be a pitfall, 
though, in that you then have less distinction between types. For instance

    typedef FirstInterface SecondInterface;

would then be pointless, since they are (implicitly?) convertible to 
each other.

If you needed to explicitly specify the conversion, that problem might 
go away. And with compile-time introspection, you could implement it 
just in the compiler, without any compiler assistance:

    T convert(T, U)(U value)
    {
        static assert((is(U == interface) || is(U == class)) && is(T == 
interface));
        // Check that U conforms to T
        // Now grab pointers to each of U's relevant functions from its 
vtbl, and generate a new vtbl and object for T
    }

> - interface_maps
> With implicit implementation of interfaces the concept_map idea might come in handy for interfaces as well, allowing to do some adjustments to make a class conforming to an interface.
I agree. I think, with reflection, this could be implemented in userland 
like above. Perhaps also relevant is C#'s explicit interface 
implementation, which (IIRC) allows you to implement the interface under 
different names (but only within the class; not in retrospect).

> - why not make concepts obligatory?
> One of the beneficial aspects of using interfaces is in my opinion that it forces you to be specific about which properties you expect from the plugged in types. This is something which is missing from generic programming and which is supposed to be improved by introducing concepts. C++ of course has to stay backwards-compatible therefore concepts will be completely optional.
> In D OTOH concepts could actually be made obligatory forcing the programmer to be explicit about the properties of the types which can be plugged into a template/generic class.
Ideally, yes.

Just of the top of my head, though, there may be practical concerns 
which prevent this.  You can do complicated things with templates in D, 
so you can have complicated requirements. Specifying such constraints 
could perhaps be difficult, lengthy, or impossible, depending on the 
syntax of your constraint specifications. Sometimes it's just not worth 
it, and making it compulsory could just make it irritating. Since it's 
effectively type-checking for your template parameters, I guess we could 
expect the same annoyances that we get with static type checking. I 
think you can conclude from this that you would almost definitely need 
some kind of back door, like a cast.

C# makes the specifications compulsory with where clauses -- most of the 
time, this is a good feature; I would perhaps even say all the time 
except for it's limitation in specification, especially of constructors. 
Of course, you can't do any where near as much with C# generics as with 
D templates.

C++'s concepts seem to be quite expressive. Perhaps they would be 
expressive enough to make compulsory. Perhaps backwards compatibility 
with pre-concepts code is the reason they aren't compulsory.

Cheers,

Reiner