Lutger wrote:
Ok, I sort of assumed you talked about explicit instantiation like in C#.
For any type that implements a clone operation for example, you have to
derive it from ICloneable if you are to use it as a generic parameter. In
addition, in your template, you have to explicitly bring all operations
under in an interface. (This is the bloat part). Now say I have a type from
another library that supports cloning, has the same interface as ICloneable,
but doesn't derive from it. You are forced to create a wrapper for it that
derives from ICloneable. (the workaround). Also, there is the complication
of what to do with arithmetic types.
the arithmetic types issue is not a problem in D since the relevant
operators are non-static in D.
I don't understand what's the bloat here. here's an example:
interface I { // you mean this interface is bloat ?
void func() ;
}
class C(T : I) {
...
}
regarding the workaround issue, we agreed already that verifying a type
against a concept is done structurally.
possible solutions are that identical concepts with different names are
implicitly castable to each other. the compiler will treat it similar to
aliases.
suppose that you got a type implementing the MyClonable interface which
is structurally identical to the standard ICloneable interface.
void foo(T : ICloneable) (T t) {...}
foo() should work with your type because for the compiler both
interfaces represent the same concept.
this restricts "duck-typing" to the concept level only.
another option is that instead of this being done by the compiler, the
programmer could specify this relation by:
alias MyConcept Iconcept;
// compile type-checks here for conformance and registers this identity
This idea probably can be further refined. I think My general direction
here is to have C++ concepts but with a *much* better syntax and more
tightly integrated into the type system. In C++ it feels like an
optional addon added as an after thought.
