concepts and interfaces

[janderson]

janderson wrote:
> Martin Hinsch wrote:
>> Inspired by this video (linked by an earlier post, and very 
>> interesting; I really hope that D will get something similar)
>>
>> http://video.google.com/videoplay?docid=-1790714981047186825&hl=en
>>
>> I started to think about the relation of concepts and interfaces.
>> In a way both serve very similar purposes, namely supporting 
>> polymorphism. The major difference is of course that one is used at 
>> compile time and the other one at run-time. Still, in the end both are 
>> just a way to describe the constraints which have to be fulfilled by a 
>> type in order to be usable in a specific generic way.
>> Interestingly the syntactic differences are nevertheless considerable. 
>> My main point in this post is that this is mainly for historical 
>> reasons and that it might be beneficial to think about making 
>> interfaces and concepts more similar to each other.
>>
>> Some more specific thoughts:
>>
>> - 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).
>>
>> - 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.
>>
>> - 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.
>>
>> Just some food for thought.
>>
>> cheers
>> Martin Hinsch
> 
> I'm not sure D necessarily needs to support this the same way as C++. 
> However the C++ developers of concepts are very smart people and have 
> obviously put a lot of thought into this.  We should consider all options.
> 
> It would be nice when C++0x comes out we could say, D's had all these 
> features for years.  If your going to switch, why not switch to D.
> 
> -Joel


Just a thought, could concepts possibly be jammed into contracts?

void Foo(T)(T t)
in
{
     static assert(IsIterator!(T));
}
body
{

}

How IsIterator is defined is another matter.  Perhaps a compile-time 
function:

bool IsIterator(T)()
{
	if (T contains opEquals)
	{
		return true;
	}
	ect...
}

Something like that.  Probably would need some more thought to be a 
complete solution.

-Joel