Bug 1856 – [Tracker] Outstanding template issues

D has some compile-time programming features that make other languages weep with jealousy. However, the core features, those that have worked in C++ for years, are still buggy and incomplete. These buggy & incomplete features make using templates in D unnecessarily painful. Consider this a sort of meta-bug-report summarizing what I think are the main issues. In all honesty I'm just submitting this as a bug so Andrei will see it (and hopefully comment). ----------------------- 1) Incomlete IFTI / type deduction: 1a) Numerous IFTI type deduction bugs A quick bugzilla search on the term "IFTI" turned up the following unresolved IFTI issues http://d.puremagic.com/issues/show_bug.cgi?id=493 http://d.puremagic.com/issues/show_bug.cgi?id=617 http://d.puremagic.com/issues/show_bug.cgi?id=756 http://d.puremagic.com/issues/show_bug.cgi?id=1454 http://d.puremagic.com/issues/show_bug.cgi?id=1650 http://d.puremagic.com/issues/show_bug.cgi?id=1807 http://d.puremagic.com/issues/show_bug.cgi?id=1848 And I know about this other one because I reported it: http://d.puremagic.com/issues/show_bug.cgi?id=1661 There are probably others. Basically, support for template parameter deduction is poor, and it's quite easy to find cases where IFTI fails. The problem is compounded by difficult-to-understand error messages from the compiler and lack of instantiation stack traces. 1b) *specialization* of any kind in D disables IFTI. I had presumed this was just a temporary situation, but it shows no signs of getting any attention any time soon. This makes it significantly more difficult to write template code in D than it is in C++. You end up needing hacks like wrapping one template with another that does explicit instantiation of the first one. 1c) Furthermore, having only IFTI (i.e. functions only) is limiting, as well. There's no reason why ICTI and ISTI (class and struct instantiation) shouldn't work. For instance, if you make a class like class Class(T) { this(T x) {} } It should be possible to write auto C = new Class(2.0f); There is enough information there to deduce that it should instantiate Class!(float). You can work around this by making factory functions, but why should that be necessary? ------------------------ 2) Lack of Overloading: The second big category of headaches comes from lack of overloading. 2a) Functions and templates. You can't have a function and a template with the same name. C++ has no problem with this. I don't see why D should. The workaround isn't terribly onerous, but then again neither should it be a terribly difficult fix, I suspect. 2b) Templates and templates This is worse. You can't overload templates with other templates of the same # of parameters even if the signatures are unambiguious. This is where the infamous "dummy=void" hack comes in. 2c) No ADL: Not being able to overload templates across modules kills user extensibility of templates. It's a very common pattern in C++ code. A generic class in a library uses Traits<T> to get info about a class. If you make a new MyT, you can integrate your class into the lib by providing your own specialization of Traits!(MyT). In D to get this you have to modify the original module where Traits! is defined. It's like saying that to extend a class from a library you should edit the library's source code and add a member to the class there. It is the antithesis of modular code. I hope this will be fixed in D2 by the overload sets stuff, but I consider D1 broken for lack of this. - Yes, I know there are workarounds for most of these 1) and 2) issues -- believe me, I'm all too familiar with them -- but the problem is that in any significantly template heavy code, the workarounds touch just about every single function, and worse, force you to contort your code in ways that makes it hard to write and hard to maintain. (Everything turns into big opaque functions filled with static ifs: BigFunction(T...)(T args) { /*heaps of static ifs*/ } ) Looking at that function signature tells you nothing, and it's significantly harder to write and maintain than the equivalent version using pattern matching on arguments various different specializations. Finally 3) is something that I can't really call a bug, though I would sure like to: ------------------- 3) Lack of struct inheritance: In most any significantly advanced template using library, you will find instances of the "Curiously Recurring Template Pattern" or CRTP. (http://en.wikipedia.org/wiki/Curiously_Recurring_Template_Pattern) CRTP lets you do things like compile time polymorphism. In my experience it is most used with value-type classes in C++ which make most sense as "struct" in D. I hope the WalterAndrei.pdf proposal of using "alias SuperStruct this" will be able to support this. Although I think it would be a lot easier on everyone if structs could just use the regular inheritance syntax and it was understood that because they are structs it is purely a non-virtual inheritance.

I appreciate your putting together detailed bug reports and posting them here, but I just request that separate issues, such as (3), should be in separate reports. Otherwise, it's hard to figure out how to resolve a report when there are different resolutions to the different issues.

Sorry about that. It was a newsgroup post initially and it looked like it wasn't going to get much attention over there. So I just pasted it here rather than properly separating the issues like I should have.

I just noticed that function-vs-template overloading was one of the items mentioned in WalterAndrei.pdf. However, there it says "the function is not preferred over the template" so that means this would be an error? void foo(int i); void foo(T)(T i); That doesn't seem so good. Why not treat functions like specializations?

[email protected] wrote: > http://d.puremagic.com/issues/show_bug.cgi?id=1856 > > > > > > ------- Comment #3 from [email protected] 2008-02-26 12:51 ------- > I just noticed that function-vs-template overloading was one of the items > mentioned in WalterAndrei.pdf. > > However, there it says "the function is not preferred over the template" so > that means this would be an error? > > void foo(int i); > void foo(T)(T i); > > That doesn't seem so good. Why not treat functions like specializations? I think that's the idea. In C, when there's a function and a template, the compiler ALWAYS chooses the function. No matter how inappropriate the function is.

(In reply to comment #4) > [email protected] wrote: > > http://d.puremagic.com/issues/show_bug.cgi?id=1856 >> > However, there it says "the function is not preferred over the template" so > > that means this would be an error? > > > > void foo(int i); > > void foo(T)(T i); > > > > That doesn't seem so good. Why not treat functions like specializations? > > I think that's the idea. In C, when there's a function and a template, the > compiler ALWAYS chooses the function. No matter how inappropriate the function > is. So you're saying int x = 3; foo(3); would call the function instead of the generic template? If so then ok. If it's an ambiguity error, then that's ok too I suppose. But if it prefers the template in this case, that seems like it could lead to unexpected results.

[email protected] wrote: > http://d.puremagic.com/issues/show_bug.cgi?id=1856 > > > > > > ------- Comment #5 from [email protected] 2008-03-10 04:36 ------- > (In reply to comment #4) >> [email protected] wrote: >>> http://d.puremagic.com/issues/show_bug.cgi?id=1856 >>>> However, there it says "the function is not preferred over the template" so >>> that means this would be an error? >>> >>> void foo(int i); >>> void foo(T)(T i); >>> >>> That doesn't seem so good. Why not treat functions like specializations? >> I think that's the idea. In C, when there's a function and a template, the >> compiler ALWAYS chooses the function. No matter how inappropriate the function >> is. > > So you're saying > int x = 3; > foo(3); > would call the function instead of the generic template? > If so then ok. Yes. > If it's an ambiguity error, then that's ok too I suppose. > But if it prefers the template in this case, that seems like it could lead to > unexpected results. short x=3; foo(x) would call the template, not the function. IIRC C++ would use the function.

The standard protocol for tracker issues such as this is to list the issues being tracked as dependencies. Moreover, the correct way to link to other bugs is to write simply bug 493 or issue 617 Far better than posting a full URL, for a few reasons.

Would anyone object to me removing the last dependency and closing this bug. issue 1807 is the only remaining open bug for the linked entries issue 6082 covers "1c" of the initial description issue 12216 I believe covers "2c No ADL" in the D way The other items have already been resolved, I think 3 is invalid for D (as mentioned we have alias this) If there is objection I'll add the remaining dependencies which I've listed.

(In reply to comment #8) > Would anyone object to me removing the last dependency and closing this bug. Not from me, since we use keywords rather than tracker bugs to keep track of categories.

Closing this meta bug as fixed, the following bugs remain but will be tracked separate from this meta bug. issue 1807 is the only remaining open bug for the linked entries issue 6082 covers "1c" of the initial description issue 12216 I believe covers "2c No ADL" in the D way