What's wrong with D's templates?

[Don]

yigal chripun wrote:
> Lutger Wrote:
> 
>> 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.
> 
> The way I see it we have three options:
> 
> assume we have these definitions:
> interface I {...}
> class Foo : I {...}
> class Bar {...} // structurally compatible to I
> 
> template tp (I) {...}
> 
> 1) .Net nominative typing:
> tp!(Foo) // OK
> tp!(Bar) //not OK
> 
> 2) structural typing (similllar to Go?)
> tp!(Foo) // OK
> tp!(Bar) // also OK
> 
> 3) C++ style templates where the compatibility check is against the *body* of the template.
> 
> of the three above I think option 3 is the worst design and option 2 is my favorite design. I think that in reality you'll almost always want to define such an interface and I really can't think of any useful use cases for an unrestricted template parameter as in C++. 

You forgot option 4:

4) D2 constrained templates, where the condition is checked inside the 
template constraint.

This is more powerful than option 2, because:

(1) there are cases where you want MORE constraints than simply an 
interface; and (2) only a subset of constraints can be expressed as an 
interface.
Also a minor point: (3) interfaces don't work for built-in types.

Better still would be to make it impossible to compile a template which 
made use of a feature not provided through a constraint.