What's wrong with D's templates?

[yigal chripun]

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++. 

If you think of templates as functions the compiler executes, the difference between the last two options is that option 2 is staticly typed vs. option 3 which is dynamicaly typed. We all use D because we like static typing and there's no reasone to not extend this to compile-time as well.