concepts and interfaces

[Johan Granberg]

Martin Hinsch wrote:

> James Dennett Wrote:
> 
>> 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
> 
> Plus, the charme of C++ concepts is that they are completely separate
> entities with a syntax which is very similar to a class declaration. IMHO
> that makes it very easy to really think of them as abstract reusable
> entities which describe a _concept_.

It's like a metaprogramming typesystem, extending type correctness to
template code. (hope something like this gets adopted for D)