On 28/11/2010 00:19, Jonathan M Davis wrote:
On Saturday 27 November 2010 14:59:09 BLS wrote:
On 27/11/2010 16:59, Torarin wrote:
2010/11/27 Andrei Alexandrescu<[email protected]>:
We use template constraints for that kind of stuff.
Andrei
Yes, and that's great, but is there a way to check whether a template
argument matches a defined interface?
I could not resist..
We should have Implements!
Luca has done some work on it.. but it does not compile anymore. However
I think the intension is clear.
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&a
rticle_id=101673
If you're checking whether it implements an interface, then : should work just
like it does with classes. If you're checking whether it has the same functions
that an interface requires, then you're not really using interfaces correctly.
structs don't implement interfaces. Classes do that. So, either make it a class,
or don't use interfaces. If you want to verify that a struct has particular
functions needed for the template function in question, then just check whether
calling them compiles ( e.g. __traits(compiles, foo.bar()) ). If you have a set
of functions that are expected to be there (for instance, to verify that the
given type is a certain type of range), then just create template which checks
for each of the functions that are supposed to be there and use the template (
e.g. isForwardRange!T ). Interfaces and structs don't have anything to do with
each other.
- Jonathan M Davis
Thanks for taking the time to explain. I've copypasted.
However,
Given that dCollections enable me to change the underlaying algorithm
(say I can replace the default RBTree with SkipList) In order to so that
I have to fulfil some requirements. And now, I guess that is what I am
talking about. I want a guarantee that my skiplist implementation
fulfills the cursor (a structure) requirements.
So now what is wrong with the contract from dCollections I am asking
for. Please note that dCollections implements cursors as well as ranges.
Bjoern
