Thread overview
[Issue 9022] New: IFTI should support enclosing type/scope deduction
Nov 14, 2012
Kenji Hara
Nov 14, 2012
Kenji Hara
Nov 16, 2012
Kenji Hara
Nov 17, 2012
timon.gehr@gmx.ch
Dec 21, 2012
Kenji Hara
Jun 27, 2013
Walter Bright
November 14, 2012
http://d.puremagic.com/issues/show_bug.cgi?id=9022

           Summary: IFTI should support enclosing type/scope deduction
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: DMD
        AssignedTo: nobody@puremagic.com
        ReportedBy: k.hara.pg@gmail.com


--- Comment #0 from Kenji Hara <k.hara.pg@gmail.com> 2012-11-13 18:33:31 PST ---
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.)

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
November 14, 2012
http://d.puremagic.com/issues/show_bug.cgi?id=9022



--- Comment #1 from Kenji Hara <k.hara.pg@gmail.com> 2012-11-13 18:38:28 PST ---
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);
}
---

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
November 14, 2012
http://d.puremagic.com/issues/show_bug.cgi?id=9022


bearophile_hugs@eml.cc changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bearophile_hugs@eml.cc


--- Comment #2 from bearophile_hugs@eml.cc 2012-11-13 19:13:31 PST ---
(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?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
November 14, 2012
http://d.puremagic.com/issues/show_bug.cgi?id=9022



--- Comment #3 from bearophile_hugs@eml.cc 2012-11-13 19:14:33 PST ---
See also the "Path-Dependent Types" of Scala language:

http://stackoverflow.com/questions/2693067/what-is-meant-by-scalas-path-dependent-types

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
November 16, 2012
http://d.puremagic.com/issues/show_bug.cgi?id=9022


Kenji Hara <k.hara.pg@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |pull


--- Comment #4 from Kenji Hara <k.hara.pg@gmail.com> 2012-11-16 01:39:24 PST ---
https://github.com/D-Programming-Language/dmd/pull/1296

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
November 17, 2012
http://d.puremagic.com/issues/show_bug.cgi?id=9022


timon.gehr@gmx.ch changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |timon.gehr@gmx.ch


--- Comment #5 from timon.gehr@gmx.ch 2012-11-17 05:01:56 PST ---
(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);

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
December 21, 2012
http://d.puremagic.com/issues/show_bug.cgi?id=9022



--- Comment #6 from Kenji Hara <k.hara.pg@gmail.com> 2012-12-20 16:41:06 PST ---
*** Issue 8700 has been marked as a duplicate of this issue. ***

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
June 27, 2013
http://d.puremagic.com/issues/show_bug.cgi?id=9022



--- Comment #7 from github-bugzilla@puremagic.com 2013-06-26 22:28:56 PDT ---
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

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
June 27, 2013
http://d.puremagic.com/issues/show_bug.cgi?id=9022


Walter Bright <bugzilla@digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |bugzilla@digitalmars.com
         Resolution|                            |FIXED


-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------