Thread overview | |||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
|
November 14, 2012 [Issue 9022] New: IFTI should support enclosing type/scope deduction | ||||
---|---|---|---|---|
| ||||
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 [Issue 9022] IFTI should support enclosing type/scope deduction | ||||
---|---|---|---|---|
| ||||
Posted in reply to Kenji Hara | 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 [Issue 9022] IFTI should support enclosing type/scope deduction | ||||
---|---|---|---|---|
| ||||
Posted in reply to Kenji Hara | 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 [Issue 9022] IFTI should support enclosing type/scope deduction | ||||
---|---|---|---|---|
| ||||
Posted in reply to Kenji Hara | 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 [Issue 9022] IFTI should support enclosing type/scope deduction | ||||
---|---|---|---|---|
| ||||
Posted in reply to Kenji Hara | 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 [Issue 9022] IFTI should support enclosing type/scope deduction | ||||
---|---|---|---|---|
| ||||
Posted in reply to Kenji Hara | 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 [Issue 9022] IFTI should support enclosing type/scope deduction | ||||
---|---|---|---|---|
| ||||
Posted in reply to Kenji Hara | 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 [Issue 9022] IFTI should support enclosing type/scope deduction | ||||
---|---|---|---|---|
| ||||
Posted in reply to Kenji Hara | 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 [Issue 9022] IFTI should support enclosing type/scope deduction | ||||
---|---|---|---|---|
| ||||
Posted in reply to Kenji Hara | 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: ------- |
Copyright © 1999-2021 by the D Language Foundation