Bug 4508 – tuples should be indexable with foreach over range

The following should really work, as long as the bounds of the foreach loop are known at compile time: import std.typecons; void main() { auto tup = tuple(1, "foo", 3.0).expand; foreach(i; 0..tup.length) { auto val = tup[i]; } }

I think this is a bad idea, in this form. So I suggest to close this issue. I prefer this syntax much more: static foreach(i; 0..tup.length) {

`foreach (e; seq)` works at compile time for an AliasSeq, so I don't see why `foreach (i; low..high)` can't make `i` known at compile-time if the bounds are known. I think we should rename this bug to apply to any CT-knowable index in a ForeachRangeStatement.

(In reply to Nick Treleaven from comment #2) > `foreach (e; seq)` works at compile time for an AliasSeq, so I don't see why > `foreach (i; low..high)` can't make `i` known at compile-time if the bounds > are known. Can `i` be made known at compile-time without unrolling the loop (in the binary)? Surely we don't want to unroll every loop that can possibly be unrolled. For example, it would be very surprising if the compiler unrolled a loop like `foreach (i; 0 .. uint.max) writeln(i);`, generating gigabytes of machine code.

In that case, perhaps we could use `static foreach` as in comment 1.

With static foreach you can do this, and AFAICT is exactly what is required: import std.typecons; void main() { auto tup = tuple(1, "foo", 3.0).expand; static foreach(i; 0..tup.length) {{ auto val = tup[i]; }} }