Bug 1878 – foreach does not handle integral types appropriately

ubyte limit = whatever(); ubyte x; foreach (e; 0 .. limit) x = e; does not compile with warnings enabled. The compiler should recognize that a compile-time constant (in this case 0) is passed in and choose the tightest type (in this case ubyte) for iteration.

I think a language change might end up breaking code which assumes the index variable is always size_t. The simplest workaround is to type the index variable: foreach (ubyte e; 0 .. limit) writeln(e); Otherwise if we want type inference we could implement a library function: import std.stdio; struct Walk(T) { T idx; T max; @property T front() { return idx; } @property void popFront() { ++idx; } @property bool empty() { return !(idx < max); } } auto walk(L, U)(L lwr, U upr) { assert(lwr <= U.max); return Walk!U(cast(U)lwr, upr); } void main() { ubyte limit = 10; ubyte x; foreach (e; walk(0, limit)) { writefln("%s %s", typeid(e), e); // type is ubyte } }

A wider benchmark: import std.typetuple: TypeTuple; import std.range: iota; void main() { foreach (T; TypeTuple!(byte, ubyte, short, ushort, int, uint, long, ulong)) foreach (i; 0 .. cast(T)10) pragma(msg, T, " ", typeof(i)); pragma(msg, ""); foreach (T; TypeTuple!(byte, ubyte, short, ushort, int, uint, long, ulong)) foreach (i; iota(0, cast(T)10)) pragma(msg, T, " ", typeof(i)); } byte int ubyte int short int ushort int int int uint uint long long ulong ulong byte int ubyte int short int ushort int int int uint uint long long ulong ulong

This bug is also the source of many false positives when bug 259 gets fixed. The problem is that ForeachRangeStatement is using typeCombine, which does the C style integer promotion. It should probably use the ?: combine logic instead.

I checked the difference between CondExp (?:) and ForeachRangeStatement. The former only has a special case when the types of the two expressions are equal. It would fix foreach(i;ubyte..ubyte) and similar, but would not address the issue raised by the OP. It's still worth merging the logic of CondExp with ForeachRangeStatement, though, if only for predictability. In fact, a?0:ubyte should similarly not evaluate to 'int' but to 'ubyte', for the exact same reasons. https://github.com/D-Programming-Language/dmd/pull/2538

Commit pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/565caec167fa303cb2320a2c6d8f957f06d07008 Merge pull request #2538 from lionello/bug1878 foreach range uses same logic as ?: for type deduction

Currently this works: ubyte whatever() { return 10; } void main() { ubyte limit = whatever(); ubyte x; foreach (ubyte e; 0 .. limit) x = e; }

This got merged a while back: https://github.com/D-Programming-Language/dmd/commit/565caec167fa303cb2320a2c6d8f957f06d07008