493 – Partial IFTI does not work

IFTI should try to deduce the parameter types for any template paramters not specified (if they don't have defaults).
--------
import std.stdio:writefln;
template foo(T,S)
{
 void foo(T t, S s) {
 writefln("typeof(T)=",typeid(typeof(T))," typeof(S)=",typeid(typeof(S)));
 }
}
template bar(T,S)
{
 void bar(S s) {
 writefln("typeof(T)=",typeid(typeof(T))," typeof(S)=",typeid(typeof(S)));
 }
}
void main()
{
 // OK -- IFTI works happily
 foo(1.0,33);
 // OK -- Full template parameters specified
 bar!(double,int)(33);
 // error: I gave it T and it should be able to use IFTI to guess S, but it doesn't
 //bar!(float)(33); 
}
---------------
Not sure if this should be a bug or an enhancement, but anyway, especially with the new variadic templates I think it will become more common to want to have a few specified paramters and let IFTI guess the rest.
 templatefunc(T, Var...)(Var v) {
 [...]
 }
 templatefunc!(SomeType)(a,b,c,d,e);
 This basically isn't usable if I have to specify all the types for a,b,c, and d.

DMD 2.011 was enhanced to do this.

(In reply to comment #1)
> DMD 2.011 was enhanced to do this.
> 
And this isn't a bug in D1 because...?
As far as I can tell, the spec says only this about IFTI:
"""
Function templates can be explicitly instantiated ...
or implicitly, where the TemplateArgumentList is deduced from the types of the function arguments
"""
It doesn't say anything about only working when it's convenient or when the stars are aligned properly. The conclusion I draw is that any failure to deduce a type when the information required to deduce it is there is a bug.

By the way, that's great that it's fixed in D2.
I can confirmed that it does indeed work with 2.011 (but not with 1.075).

The new std.algorithm in DMD 2.011 uses this capability heavily.
That means porting std.algorithm to D1 is basically not practical as of D2.011. 
I'm really going to be bummed if you hold to the line that fixes like this are really "enhancements" that will not be ported to D1.

This is a bug in DMD 1.0 so I'm sure it will be fixed eventually. And since basically all real development is with D 1.0, I sincerely hope we don't have to wait forever. This ticket was originally filed in 2006. It would be nice if #1650 were fixed at some point as well, since a rather fundamental example in the D book requires it to work correctly.

Created attachment 267 [details] 
Patch to backport partial IFTI to dmd. Against llvmdc's dmd frontend. Should be similar to dmd 1.033.
I only did basic testing, but this patch seems to backport the D2 partial IFTI changes to D1.
Should this go into llvmdc proper though? If we start diverging from Walter's definition of D1 too much we'll essentially create a D 1.5... People using this feature on llvmdc couldn't switch back to dmd easily.

I don't think is a good idea either to make ldc as buggy as DMD just to be compatible =)

It's the very purpose of compatibility to replicate bugs.

(In reply to comment #8)
> It's the very purpose of compatibility to replicate bugs.
No, the very purpose of compatibility is to replicate *features*!

Added to dmd 1.038