http://d.puremagic.com/issues/show_bug.cgi?id=1856

           Summary: Outstanding template issues
           Product: D
           Version: 1.027
          Platform: PC
        OS/Version: Windows
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: bugzilla@digitalmars.com
        ReportedBy: wbaxter@gmail.com


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.


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=1856





------- Comment #1 from bugzilla@digitalmars.com  2008-02-21 00:49 -------
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.


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=1856





------- Comment #2 from wbaxter@gmail.com  2008-02-21 02:37 -------
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.


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=1856





------- Comment #3 from wbaxter@gmail.com  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?


-- 

d-bugmail@puremagic.com wrote:
> http://d.puremagic.com/issues/show_bug.cgi?id=1856
> 
> 
> 
> 
> 
> ------- Comment #3 from wbaxter@gmail.com  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.

http://d.puremagic.com/issues/show_bug.cgi?id=1856





------- Comment #5 from wbaxter@gmail.com  2008-03-10 04:36 -------
(In reply to comment #4)
> d-bugmail@puremagic.com 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.


-- 

d-bugmail@puremagic.com wrote:
> http://d.puremagic.com/issues/show_bug.cgi?id=1856
> 
> 
> 
> 
> 
> ------- Comment #5 from wbaxter@gmail.com  2008-03-10 04:36 -------
> (In reply to comment #4)
>> d-bugmail@puremagic.com 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.

http://d.puremagic.com/issues/show_bug.cgi?id=1856


smjg@iname.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |smjg@iname.com
  BugsThisDependsOn|                            |493, 617, 756, 1454, 1650,
                   |                            |1661, 1807, 1848

Bug 1856 depends on bug 617, which changed state.

Bug 617 Summary: IFTI doesn't use normal promotion rules for non-template parameters http://d.puremagic.com/issues/show_bug.cgi?id=617

           What    |Old Value                   |New Value
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED



------- Comment #7 from smjg@iname.com  2008-11-19 21:05 -------
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.


--