Overlapping functionality: IFTI, templates, is-expressions

[Russell Lewis]

As you can tell from my recent posts (and bug reports), I've been 
pounding on D's template mechanisms a lot recently.  I'm trying to build 
a parser generator using templates.  I'm now starting my 3rd major 
generation of the library, because I keep finding fundamental weaknesses 
in each method I try.

I'm writing this post to observe, publicly, that there is *A LOT* over 
overlap between functions with IFTI, template specializations, and 
is-expressions.  However, the overlap isn't perfect; AFAIK, none of 
these 3 is a strict superset of the others.  So, it looks to me like I 
can't just choose one method and stick with it.  I would like to 
advocate for two changes to the language:


1) The 3 mechanisms should be explicitly connected.  That is, 2 of them 
should be defined to just be syntax sugar of the third.  For instance, a 
template with specializations, IMHO, should be declared (in the spec) to 
be syntax sugar for one mega-template (taking a Tuple argument) where 
the various alternatives are deduced using static if() and 
is-expressions.  The spec should, of course, exactly document how each 
type of template specialization is mapped to is-expressions.  Somehow, 
IFTI should be likewise linked it, though I'm a little less clear how.

2) Templates *MUST* support multiple Tuples.  Imagine trying to declare 
a template specialization which takes a delegate (or delegate type) with 
an arbitrary number of arguments, but the template also takes an 
arbitrary number of other parameters.  I've found ways to do it which 
work for my special case, but I don't know of any way to do it in the 
general case.


In truth, I have more ideas than just the two above, but the two above 
would solve most of my issues.

Thoughts?
	Russ