Bug 9022 – IFTI should support enclosing type/scope deduction

This code doesn't work, but I think it should do. --- class C { struct X {} } void foo(T)(T, T.X) { static assert(is(T == C)); } void main() { auto c = new C(); auto cx = C.X(); foo(c, cx); } --- In bug 9004, similar case has been introduced, but this enhancement does not support that. --- // From bug 9004 description: struct Foo(_T) { alias _T T; } void bar(FooT)(FooT foo, FooT.T x) { } void main() { Foo!int foo; bar(foo, 1); // line 8 --> should fail } --- At line 8, the deduction from int to FooT.X should fail, because int type has no enclosing scope. (If FooT is already deduced, then it may seem to be able. However, it will introduce an IFTI order dependency between function parameters. So it is an another enhancement, and I don't propose it here.)

Another case which should be supported: --- module test; class C { struct X {} } void foo(alias M)(M.C, M.C.X) { static assert(__traits(isSame, M, test)); // M is deduced to the module 'test' which enclosing class C } void main() { auto c = new C(); auto cx = C.X(); foo(c, cx); } ---

(In reply to comment #0) > However, it will > introduce an IFTI order dependency between function parameters. What are the difficulties or the dangers of introducing an IFTI order dependency between function arguments?

See also the "Path-Dependent Types" of Scala language: http://stackoverflow.com/questions/2693067/what-is-meant-by-scalas-path-dependent-types

(In reply to comment #2) > (In reply to comment #0) > > > However, it will > > introduce an IFTI order dependency between function parameters. > > What are the difficulties or the dangers of introducing an IFTI order > dependency between function arguments? No introduction of order dependency is necessary. IFTI would have to become a fixed-point seeking inference algorithm. But it really should anyways, eg. [1,2,3,4].map(a=>a*2), should work, where 'map' is generic. (map(a=>a*2,[1,2,3,4]) should work too). The difficulty lies in formalizing and implementing the semantics of IFTI, delegate parameter and return type deduction and template default arguments precisely. Eg: auto foo(Z=int,A,B,C)(A delegate(Z) x, B delegate(A) y, C delegate(B) z){ ... } foo(x=>x, y=>y+1.0f, z=>[1,2,z]); should instantiate foo!(int, int, float, float[]) I'd suggest: 1: Infer delegate/function pointer parameter types and full types of everything else until a fixed point is reached. 2: Infer delegate return types where possible. 3: Repeat 1, 2 until a fixed point is reached 4: Resolve template default arguments that are independent of unresolved arguments 5: Repeat 3, 4 until a fixed point is reached 6: Check if all arguments have been found. The split of 1 and 2 is not strictly necessary but it would make an implementation of some kind of type unification simpler in the future. Also taking into account curried delegates would improve the process further, eg: auto foo(T)(T delegate (T) delegate (T) dg); foo(x=>(int y)=>x+y);

*** Issue 8700 has been marked as a duplicate of this issue. ***

Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/d5b412b62136e20c9e291055d9ac1219cac698ac fix Issue 9022 - IFTI should support enclosing type/scope deduction https://github.com/D-Programming-Language/dmd/commit/42d92fad24f4dda721db377b729951da57c27e27 Merge pull request #1296 from 9rnsr/fix9022 Issue 9022 - IFTI should support enclosing type/scope deduction