What's wrong with D's templates?

[Yigal Chripun]

On 21/12/2009 22:41, Kevin Bealer wrote:
> dsimcha Wrote:
>
>> == Quote from Yigal Chripun (yigal100 at gmail.com)'s article
>>> but even more frustrating is the fact that template compilation
>>> bugs will also happen at the client. There's a whole range of
>>> designs for this and related issues and IMO the C++ design is by
>>> far the worst of them all. not to mention the fact that it isn't
>>> an orthogonal design (like many other "features" in c++). I'd
>>> much prefer a true generics design to be separated from
>>> compile-time execution of code with e.g. CTFE or AST macros, or
>>> other designs.
>>
>> Since generics work by basically casting stuff to Object (possibly
>> boxing it) and casting back, I wonder if it would be easy to
>> implement generics on top of templates through a minimal wrapper.
>> The main uses for this would be executable bloat (for those that
>> insist that this matters in practice) and allowing virtual
>> functions where templates can't be virtual.
>
> In C++ you could define a MyObject and MyRef (smart pointer to
> Object) types that implement the methods you need (like comparisons)
> as virtual functions that are either pure or throw exceptions.  Then
> just define a non-template class that inherits from (or just
> aggregates and wraps) a vector<MyRef>  and map<MyReft, MyRef>.  Now
> you can use this map and vector code to build whatever solution you
> need, using dynamic_cast<T>  to insure the types are what you want.
>
> If you want you can throw a type safe wrapper that uses
> dynamic_cast<T>  around this, as long as all the methods of that
> class are inlined, it should have no extra bloat.  Now your back at
> the Java level of expressiveness.
>
> I wonder, though, if you actually save anything.  Since
> vector::operator[](size_t) is just an array index that will get
> inlined into your code, I think it should have much *less* code bloat
> in your executable than a function call (to virtual MyRef
> vector<MyRef>::operator[](size_t)) plus dynamic casts to figure out
> if all the types are castable.
>
> Movie Poster: Dr. Stroustrouplove: or How I Stopped Worrying and
> Learned to Love the Bloat.
>
> As for mixing template code and client code, is it that big of a deal
> in practice?  If you are making something big enough to be worth
> patenting, won't most of the "heavy lifting" classes probably not be
> templates?  Unless you are marketing template/container libraries
> specifically I guess...
>
> Personally I'm reluctant to buy that sort of thing from someone if I
> *can't* see the source.  If I need a class like "vector", in practice
> I need to be able to dig into its methods to see what they do, e.g.
> is it really guaranteed that storage is contiguous, etc.  On the
> other hand, if I was buying code to print a Word document to a pdf
> file, I could accept that I don't need to look into the code.  But
> something like vector<>  or map<>  ends up getting so "intimate" with
> the rest of my design that I want to know how it works in detail just
> as an end-user.  (Yeah, yeah, I know encapsulation says I shouldn't
> have to.)
>
> I think performance outweighs the needs of any particular business
> model, especially when you can do your own Object based version if
> you need to.  I agree there should be ways to hide the implementation
> from the client, but if templates aren't one of them, then just
> factor that into where and how you use templates and when you use OO
> and virtual instead.  It's enough that it's possible and practical to
> hide your impl, you don't need *every* language feature to make that
> its #1 priority.
>
> The performance / impl-hiding conflict is a fundamental problem -- if
> the user's compiler can't see the template method definitions, then
> it can't optimize them very well.  If it can, then the user can too.
> Any method of compiling them that preserves enough info for the
> compiler to work with will probably be pretty easily and cleanly
> byte-code-decompilable.
>
> Kevin
>

a few points:
Java generics are poorly designed and create holes in the type system.
Some of the designers of the language admit this openly. This 
implementation doesn't represent the general concept.

your performance / impl-hiding conflict doesn't exist. I already 
mentioned in a previous post how the C# compiler handles generics. Also 
you assume the same (broken) compilation model as in C++. don't.