On Thursday, September 27, 2012 00:05:41 bearophile wrote: > Jonathan M Davis: > > So, this really makes no sense to me at all. > > I agree that foobar examples aren't so good. But it's true that > Tuple() gives some troubles regarding missed structural typing: > > > import std.stdio, std.typecons; > alias Tuple!(float, float) T1; > alias Tuple!(float,"x", float,"y") T2; > void foo1(T1 t) {} > void foo2(T2 t) {} > void main() { > auto p1 = T1(1, 2); > auto p2 = T2(1, 2); > p1 = p2; // no error > p2 = p1; // no error > T1[] a1; > T2[] a2; > a1 = a2; // error > a2 = a1; // error > foo1(p2); // error > foo2(p1); // error > } > > > Generally I think "p1 = p2;" is OK, while "p2 = p1;" is not so > good, because T2 is more specialized. > > There are several other more or less similar things related to > structural typing of tuples that a well implemented built-in > tuple type will need to address. In Bugzilla there are some open > bug reports on similar matters. Fixing them with the library > defined tuples is hard. Of course a possible solution is to > improve the D language to allow the programmer to specify very > good struct-based tuples in library code, I think but doing this > is more complex than implementing good built-in tuples.
It sounds to me like the reason that structural typing is needed is because Tuple allows you to name its fields, which I've always thought was a bad idea, and which a built-in tuple definitely wouldn't do. If you couldn't name its fields, then any Tuple containing the same sequence of types would be the same type. So, the problem is caused by a feature that built-in tuples wouldn't even have. - Jonathan M Davis