Bug 3092 – Indexing a tuple produces a tuple containing the indexed element

template Foo(A...) { alias A[0] Foo; } void foo() { } static assert(is(Foo!(int, foo) == int)); void main() { } Error: static assert (is((int) == int)) is false ---- This one was slightly annoying as it came along with http://d.puremagic.com/issues/show_bug.cgi?id=2229, which gets in the way regularly and which is almost a year old now.

A workaround (which doesn't mean that the bug is not critical): template StaticTuple(A...) { alias A StaticTuple; } template Foo(A...) { alias StaticTuple!(A[0])[0] Foo; } void foo() { } static assert(is(Foo!(int, foo) == int)); void main() { }

Where it's got (int) as a distinct type from, I don't get either. It's always been my understanding that a 1-element tuple and its element are one and the same.

(In reply to comment #2) > Where it's got (int) as a distinct type from, I don't get either. It's always > been my understanding that a 1-element tuple and its element are one and the > same. I don't think that has ever been the case..

I just rediscovered this bug and reported it on the ldc bugtracker first, see http://www.dsource.org/projects/ldc/ticket/435 . It's a frontend bug, and only happens when you pass more than one argument to the template. I will copy my findings here (using ldc to compile, but the result is the same with dmd v2.049 and v1.056). There are various bugs with the "..." syntax for creating tuples, but I think they all root back to types being errously converted to singletons of itself when the number of arguments is >= 2. // file tup_bug.d template TupleBug(values...) { alias values[0] v0; alias values[0][0][0][0][0] chain; pragma(msg, "values: ", values); pragma(msg, "v0: ", v0); pragma(msg, "values[0]: ", values[0]); pragma(msg, "chain: ", chain); } pragma(msg, "-- TupleBug!(int):"); alias TupleBug!(int) _; pragma(msg, "\n-- TupleBug!(int, \"foo\"):"); alias TupleBug!(int, "foo") _0; void main() {} Output of ldc 0.9.2 is $ldc tup_bug.d -- TupleBug!(int): values: (int) v0: int values[0]: int chain: int[0LU][0LU][0LU][0LU] -- TupleBug!(int, "foo"): values: tuple((int),"foo") v0: (int) values[0]: int chain: (int) Expected output for TupleBug?!(int, "foo"): values: tuple(int,"foo") v0: int values[0]: int chain: int[0LU][0LU][0LU][0LU] The output for TupleBug?!(int) is ok, but when the number of parameters is 2 or greater, then all types T in the parameter list are implicitly converted to a singleton tuple (T), as can be seen here in case of T=int. Even worse, you can not index the singleton tuple, it just returns a copy of itself, which is evident when looking at the output of chain. In TupleBug?!(int), chain is a multidimensional array, which is correct. But in TupleBug?!(int, "foo"), the output of chain is just (int). I also think the usage of tuple(...) and (...) in the output is inconsistend, it seems like tuple(...) is used for tuples of length >= 2 and (...) is used for singleton tuples only. I would use tuple(...) in both cases. ============================================================================ One really annoying consequence that's bugging me is that assigning names to template parameters via aliasing is not possible: // file tup_bug_consequence.d struct TypeAndName(args...) { alias args[0] type; // "..." bug => type = (args[0]), not args[0] const char[] name = args[1]; } template DeclVar(data) { mixin("data.type "~data.name~";"); } void main() { mixin DeclVar!(TypeAndName!(int, "foo")); pragma(msg, "foo: ", foo); pragma(msg, "typeof(foo): ", typeof(foo)); foo = 3; } I expect this to define "int foo;" inside main, but due to the "..." bug described above, that doesn't work: $ldc tup_bug_consequence.d foo : tuple(_foo_field_0) typeof(foo): (int) tup_bug_consequence.d(18): Error: foo is not an lvalue tup_bug_consequence.d(18): Error: cannot implicitly convert expression (3) of type int to (int) tup_bug_consequence.d(18): Error: cannot cast int to (int) This TypeAndName? construct is really useful for parsing template arguments of the form (Type1, "name1", ..., TypeN, "nameN"), but as soon as you try to get an alias to one of the types, everything breaks. A workaround is to always work with the parameter tuple directly and don't alias its items, but then all your templates are reduced to magic tuple indexing code that no one can understand.

Some updates: template TupleBug(values...) { pragma(msg, "values: ", values); } alias TupleBug!(int, int) _0; // prints 'values: (int, int)' alias TupleBug!(int, 1) _1; // prints 'values: tuple((int), 1)' After investigating the frontend, i can explain this behaviour: (int, int) is treated as a type by dmd, not as a tuple, but the mixed tuple (int, 1) is treated as a tuple. To see that, go to DsymbolExp::semantic in expression.c and insert the printf's like this: t = s->getType(); if (t) { // entered for TupleBug!(int, int) printf("'%s' is type\n", t->toChars()); // prints "'(int, int)' is type" return new TypeExp(loc, t); } TupleDeclaration *tup = s->isTupleDeclaration(); if (tup) { // entered for TupleBug!(int, 1) printf("'%s' is tuple\n", tup->toChars()); // prints "'values' is tuple" e = new TupleExp(loc, tup); printf("e = %s\n", e->toChars()); // prints 'e = tuple((int), 1)' e = e->semantic(sc); printf("e->semantic(sc) = %s\n", e->toChars()); // prints 'e->semantic = tuple((int), 1) return e; } I don't know if it's intended behaviour to treat type tuples separately from mixed tuples even in the frontend, but that's how it is. Type tuples don't seem to be buggy (they are not affected by any aliasing, indexing or pragma(msg,...) bugs described before). So what's really buggy are the 'true' mixed tuples. I can at least explain what causes the pragma(msg, values) bug, which currently prints tuple((int), 1). The bug is not, as it seems, that (int) is a singleton tuple containing an int, it's actually a bug in e->toChars(), which calls TupleExp::toCBuffer [that prints the 'tuple(' ')' frame], which calls argsToCBuffer, which treats every argument as an expression, but it shouldn't do that, the arguments are (int, 1), and 'int' is not an expression. When argsToCBuffer calls expToCBuffer on the int 'expression', it thinks the expression has an operator precedence lower than PREC_assign, so it put's the parantheses around the expr and produces '(int)'. A workaround is to do 'e->op = TOK_assign' in TupleExp::TupleExp when pushing a type to the tuple exps, but that's only a hack. I will try to find a proper fix and also investigate into the other bugs that mixed tuples have.

Created attachment 782 Patch for this bug created with "svn diff mtype.c", apply in the frontend directory

Created attachment 783 Testcase for dstress, add to dstress/compile/t I'm not sure about the numbering scheme in dstress, I just used the next free available number (27) for my testcase. Marked as patch, although it's for dstress and not dmd.

I have now fixed the bug, it's a trivial 7 line patch which teaches TypeSArray::resolve(...) to recognize if it's indexing a type element. Without the patch, TypeSArray::resolve(...) will create a 1-element-slice when indexing a type in a tuple. This fixes the bug described in this issue. This patch does not fix the pragma(msg, "values: ", values); bugs, which is caused by another bug I described in a previous comment. That one would also be easy to fix, it's only a formatting bug, I'm just not sure how a proper patch for that would look like. I also tested dmd rev 714 (that one in branch dmd1.x) and my patched version of it in dstress. No improvements, regressions or changes were introduced. I then created a testcase that can be added to the dstress/compile/t directory, which passes with my patch applied, but fails in dmd rev 714.

(In reply to comment #8) > I have now fixed the bug, it's a trivial 7 line patch which teaches > TypeSArray::resolve(...) to recognize if it's indexing a type element. Without > the patch, TypeSArray::resolve(...) will create a 1-element-slice when indexing > a type in a tuple. This fixes the bug described in this issue. > > This patch does not fix the pragma(msg, "values: ", values); bugs, which is > caused by another bug I described in a previous comment. That one would also be > easy to fix, it's only a formatting bug, I'm just not sure how a proper patch > for that would look like. > > I also tested dmd rev 714 (that one in branch dmd1.x) and my patched version of > it in dstress. No improvements, regressions or changes were introduced. I then > created a testcase that can be added to the dstress/compile/t directory, which > passes with my patch applied, but fails in dmd rev 714. Sounds as though you have been running dstress. Could you please post the results somewhere? I would be very interested to see how many dstress bugs are still unfixed in the most recent DMD version.

Comment on attachment 783 Testcase for dstress, add to dstress/compile/t Remove patch type to the attached dstress test as it isn't in patch format

(In reply to comment #9) > > Sounds as though you have been running dstress. Could you please post the > results somewhere? I would be very interested to see how many dstress bugs are > still unfixed in the most recent DMD version. Sure, see here: http://drop.io/dstres_results_rev714 It contains the dstress results for dmd rev714 and my patched version. I can also test the most recent dmd version later, but my homework comes first :)

(In reply to comment #11) > (In reply to comment #9) > > > > Sounds as though you have been running dstress. Could you please post the > > results somewhere? I would be very interested to see how many dstress bugs are > > still unfixed in the most recent DMD version. > > Sure, see here: http://drop.io/dstres_results_rev714 > It contains the dstress results for dmd rev714 and my patched version. I can > also test the most recent dmd version later, but my homework comes first :) Thanks! That's exactly what I was after. There has been 1 regression since I last saw dstress results (for DMD1.051). I've created bug 5086. Don't bother redoing it with the latest DMD, there won't be any changes.

(In reply to comment #8) > I have now fixed the bug, it's a trivial 7 line patch which teaches > TypeSArray::resolve(...) to recognize if it's indexing a type element. Without > the patch, TypeSArray::resolve(...) will create a 1-element-slice when indexing > a type in a tuple. This fixes the bug described in this issue. > > This patch does not fix the pragma(msg, "values: ", values); bugs, which is > caused by another bug I described in a previous comment. That one would also be > easy to fix, it's only a formatting bug, I'm just not sure how a proper patch > for that would look like. > > I also tested dmd rev 714 (that one in branch dmd1.x) and my patched version of > it in dstress. No improvements, regressions or changes were introduced. I then > created a testcase that can be added to the dstress/compile/t directory, which > passes with my patch applied, but fails in dmd rev 714. Added to dstress, changeset 1622: http://www.dsource.org/projects/dstress/changeset/1622%3Ad402aa53926c Thanks!

https://github.com/D-Programming-Language/dmd/commit/31b955584130b890dac7786b500c31c75e19e4d8 https://github.com/D-Programming-Language/dmd/commit/fcd345d18de57faf49f972f5a6d74e0b4e2d2b4e

*** Issue 2422 has been marked as a duplicate of this issue. ***