What's wrong with D's templates?

[Lutger]

Yigal Chripun wrote:

> On 19/12/2009 01:31, Lutger wrote:
>> Yigal Chripun wrote:
>>
>>> On 18/12/2009 02:49, Tim Matthews wrote:
>>>> In a reddit reply: "The concept of templates in D is exactly the same
>>>> as in C++. There are minor technical differences, syntactic
>>>> differences, but it is essentially the same thing. I think that's
>>>> understandable since Digital Mars had a C++ compiler."
>>>>
>>>>
>> 
http://www.reddit.com/r/programming/comments/af511/ada_programming_generics/c0hcb04?context=3
>>>>
>>>>
>>>> I have never touched ada but I doubt it is really has that much that
>>>> can't be done in D. I thought most (if not all) the problems with C++
>>>> were absent in D as this summary of the most common ones points out
>>>> http://www.digitalmars.com/d/2.0/templates-revisited.html.
>>>>
>>>> Your thoughts?
>>>
>>> I don't know Ada but I do agree with that reddit reply about c++ and D
>>> templates. D provides a better implementation of the exact same design,
>>> so it does fix many minor issues (implementation bugs). An example of
>>> this is the foo<bar<Class>>  construct that doesn't work because of the
>>> ">>" operator.
>>> However, using the same design obviously doesn't solve any of the deeper
>>> design problems and this design has many of those. An example of that is
>>> that templates are compiled as part of the client code. This forces a
>>> library writer to provide the source code (which might not be acceptable
>>> in commercial circumstances) but even more frustrating is the fact that
>>> template compilation bugs will also happen at the client.
>>
>> Well yes, but the .NET design restrict the generic type to a specific
>> named interface in order to do type checking. You may find this a good
>> design choice, but others find it far more frustrating because this is
>> exactly what allows for a bit more flexibility in a statically typed
>> world. So it is not exactly a problem but rather a trade-off imho.
> 
> The .Net implementation isn't perfect of course and has a few issues
> that should be resolved, one of these is the problem with using
> operators. requiring interfaces by itself isn't the problem though. The
> only drawback in this case is verbosity which isn't really a big deal
> for this.

The drawback is not verbosity but lack of structural typing. Suppose some  
library has code that can be parametrized by IFoo and I have another library 
with a type that implements IBar, which satisfies IFoo but not explicitly 
so. Then what? Unless I have totally misunderstood .NET generics, I have to 
create some proxy object for IBar that implements IFoo just to satisfy the 
strong type checking of .NET generics. You could make the argument that this 
'inconvenience' is a good thing, but I do think it is a bit more of a 
drawback than just increased verbosity.