http://d.puremagic.com/issues/show_bug.cgi?id=2779
--- Comment #5 from Kenji Hara <k.hara...@gmail.com> 2011-07-22 08:55:03 PDT --- My patch's expansion strategy is simple, They are 'Head first' and 'No back tracking'. Example: ---- auto tup = tuple(tuple(10, "str"), tuple(3.14, [1,2]); void func(int, string, double, int[]); func(tup); // function call with tuple argument // func with Tuple!(Tuple!(int, string), Tuple!(double, int[])) Resolving overloads fails At this point, current D makes this expression error. But my patch continue to resolve overloads and rewrite expression like follows. auto __t = tup; // do not evaluate tuple many times func(__t[0], __t[1]); // func with (Tuple!(int, string), Tuple!(double, int[])) Resolving overloads fails, so go next expansion. auto __t = tup; func(__t[0][0], __t[0][1], __t[1]); // do not expand second tuple at this point // func with (int, string, Tuple!(double, int[])) Resolving overloads fails, so go next expansion. auto __t = tup; func(__t[0][0], __t[0][1], __t[1][0], __t[1][1]); // func with (int, string, double, int[]) Overload matches, so expansion is succeeded. (If we can't expand tuple anymore and resolving overloads fails, calling func becomes error.) ---- Only one head tuple is expanded on one step ('Head first'), and already expanded tuples are never re-packed ('No back tracking'). I think this rule is not so complex. It is not make current valid calling invalid. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------