Wed, 21 Oct 2009 13:41:50 -0500, Andrei Alexandrescu thusly wrote: > I don't understand what you are trying to accomplish. As far as I can > tell you want to do this: > > Tuple!(int, int) a; > a = tuple(12, 13); > int x = a.field[0];
Not only that, but also this: >>>> int d,e; >>>> Tuple!(d,e) = Tuple!(10,20); > and similar things. I have no idea why you refuse to do it that way. You somehow refuse to see that D has a tuple type which the compiler calls a tuple. Run 'strings /path/to/dmd|wc -l' and you'll see 28 instances of the word 'tuple'. If there was no built-in support, why does the executable contain the word then? Here.. >> template Z(T...) { alias T Z; } >> Z!(int,int) a; >> pragma(msg,a.stringof); I did not mention the word tuple, but guess what dmd thinks. If it is not a tuple, why does dmd output 'tuple(_a_field_0,_a_field_1)'? Apparently this does not follow the math book definition of tuple nor is the traditional FPL tuple, but a special D flavor of tuple. Walter decided to build a tuple type, but something happened and he later started restricting its use (IIRC it *was* possible to create an array of these tuples, but now it is disallowed). What is left is a half-working mess mostly useful for compile time meta-programming. It works rather nicely there (except that the auto-flattening is sometimes rather annoying), but its operation is broken on runtime. You discarded this by stating that D does not have a tuple type, you just call it a 'type that contains two ints' in my example. DMD calls it a tuple (see .stringof, error messages etc.) I can see that you try to accomplish the same things with your library provided version of tuple. But if that is the recommended way of using tuples, why there is a bug riddled version in the compiler of the same type. It is extremely exhausting to implement a new compiler for D because the reference implementation is full of bugs I mentioned in previous posts and you cannot really tell how it should work. > To effect this, there'd first be a need to eliminate the current > semantics of the comma operator. I probably find it as useless as the > next guy, and don't take one second to buy into Walter's theory that it > makes it easy to generate code (that may as well be his least convincing > argument to date), but really there's two parts to your suggestion: (1) > eliminate the comma operator, (2) make the comma operator work for > tuples. I suspect there are some syntactical issues with (2). I know that very well..