concepts and interfaces

[James Dennett]

janderson wrote:
> 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
> {
> 
> }

Not nicely, as concepts are able to affect things
like overload resolution; what's wanted if Foo
requires IsIterator(T) is not a compile-time error
about an assertion failing, but that the function
simply drop out of the overload set (so that some
other function might match).  At least, that's
the C++ way.  Of course D can be Different.

-- James