2010/10/7 bearophile <[email protected]>: > Another design decision is if tuples have a nominative or structural type, > this problem comes out in this bug report: > http://d.puremagic.com/issues/show_bug.cgi?id=4128
> Another significant problem is about naming things, currently the situation > is a mess: > http://www.digitalmars.com/d/archives/digitalmars/D/Tuple_TypeTuple_tupleof_etc_113005.html > http://d.puremagic.com/issues/show_bug.cgi?id=4113 > In the end I have suggested to name "record" the typecons tuples, and "tuple" > the typetuples. On these issues, I'm almost agreed with bearophile I think we may not use 'Tuple' as 'a structure packed values'. It is more better that 'Tuple' should *only* use as mixing sequence types and values. My proposals are: 1. We should name definitions of structures. - "Structure that all of fields have name" shuld be called 'Struct'. - "Structure that some of fields have name" shuld be called 'Odd struct'. - "Structure that none of fields have name" shuld be called 'Record'. Struct∈Odd struct∈Record 2. We remove field namming funcion from std.typecons.tuple, and rename it to Record. 3. We rename std.typetuple.TypeTuple to Tuple. -------- pseudo codes: auto a = Record!(int, int)(10, 20); auto b = Struct!(int, "x", int, "y")(100, 200); //a = b; //should not compile, named field(x, y) cannot assign to unnamed field b = a; //should compile, unnamed field can assign to named field assert(b[0] == 10); assert(b[1] == 20); auto c = OddStruct!(int, "x", int)(15, 25); //a = c; //shuld not compile, named field(x) cannot assign to unnamed field b = c; //shuld compile assert(b[0] == 15); assert(b[1] == 25); c = a; //shuld compile assert(c[0] == 10); assert(c[1] == 20); thanks. Kenji Hara.
