[Issue 1856] New: Outstanding template issues

[d-bugmail at puremagic.com]

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 at digitalmars.com
        ReportedBy: wbaxter at 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.


--