C#'s greatest mistakes

[Adam Burton]

Andrei Alexandrescu wrote:

> On 11/27/10 7:55 PM, Adam Burton wrote:
>> 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<SeeWebsiteForEmail at erdani.org>:
>>>>>> 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
>> The more I see these explanations the more I think interface is the wrong
>> word for what it is. Structs and base types have a public interface.
>> Contraints like isForwardRange are checking the public interface of the
>> type passed too them. Seems to me Ds interfaces are more like types than
>> interfaces (consider you can cast to an interface).
>>
>> Personally I think having an "implements" makes sense (that loops through
>> the methods of an interface and checks the type has matching methods, not
>> the same as having a class "implement" an interface which is more like
>> inheritance). However as you say, that is not how interfaces in their
>> current form are designed to be used so I understand why people disagree.
> 
> Walter and I discussed a number of times allowing structs to inherit
> interfaces. I even submitted an enhancement request once. Unfortunately,
> the feature wouldn't be a game-changer because interfaces are quite
> rigid - for example, you often want to enforce that a template defines a
> type. Before you know it, you need to add language to interfaces that
> makes them start looking like the stillborn C++ concepts. I think
> template constraints are a better solution.
> 
> 
> Andrei
Actually I am not disagreeing with you. I wasn't talking about a feature 
addition, just a convenience tenmplate function and change of terminology 
(which obviously couldn't happen due to TDPL). I just think having an 
implements template function adds convenience and readability. However I 
agree constraints model the idea of an interface better than 
interfaces/concepts. Most of the time I can see people expecting a Type with 
said selection of functions, so having an interface you can pass to 
implements helps for readability. As you say there are cases where this 
really doesn't model what you want well enough, therefore you can fall back 
to raw constraints which have the flexibility to do what you need.