Bug 2543 – foreach's index behaves differently for every type

The behavior of foreach index differs depending on what type of thing is being iterated. * For static and dynamic arrays, index cannot be ref but always acts like it is ref. * For associative arrays, index cannot be ref and always act accordingly. * For structs and classes, index can be either ref or non-ref,and behaves accordingly. However, ref behavior cannot be blocked it undesirable. While the current system works, it is needlessly inconsistent. The full behavior is exposed by the following example: ---- void plain(T)(T iterable) { foreach (i, v; iterable) write(i++," "); } void refer(T)(T iterable) { foreach (ref i, v; iterable) write(i++," "); } struct allow_ref { int opApply(int delegate(inout uint, inout int) dg) { int res; for (uint i=0; i<4; ++i) res = dg(i,i+1); return res; } } struct ignore_ref { int opApply(int delegate(inout uint, inout int) dg) { int res; for (uint i=0; i<4; ++i) res = dg(i+0,i+1); return res; } } struct fail_on_write { int opApply(int delegate(inout const(uint), inout int) dg) { int res; for (uint i=0; i<4; ++i) res = dg(i,i+1); return res; } } void main(string[] args) { int[] array = [1,2,3,4]; // int[4] behaves the same plain(array); // OK: "0 2" refer(array); // Error: foreach: key cannot be out or ref int[int] assoc = [0:1,1:2,2:3,3:4]; plain(assoc); // OK: "0 1 2 3" refer(assoc); // Error: foreach: index cannot be ref allow_ref custom1; plain(custom1); // OK: "0 1 2 3" refer(custom1); // OK: "0 2" ignore_ref custom2; plain(custom2); // OK: "0 1 2 3" refer(custom2); // OK: "0 1 2 3" fail_on_write custom3; plain(custom3); // Error: plain.foreachbody23.index cannot modify const refer(custom3); // Error: refer.foreachbody23.index cannot modify const } ---- A minor note: int[] calls the index "key"; int[int] calls it "index". These are either inconsistent or backward. Also, foreach can't have out-qualified elements, so the "out or" in the array error message seems odd. If I want to build something like an associative array, where the index type is mutable but the index itself cannot be modified to control the iteration, no good solution exists: * making the delegate not accept ref input fails to match foreach call * making the index const prevents even local modifications * making the index tamper-proof fails to let the user know what is happening I propose at least the following simple fixes: * foreach(i,v; array) should have "i" not control iteration * foreach(ref i,v; array) should be allowed and have the behavior currently exhibited by foreach(i,v; array) behavior Preventing foreach(ref i,v; structOrClass) is less obvious. Some possibilities: * non-ref foreach loops search first for non-ref delegates, falling back on a ref delegate is they are not available. This keeps the benefit of being albe to write a single method for all four ref/nonref cases and allows the programmer to rule out certain ref usages at compile time. I have no idea how difficult it would be to implement. While we're at it, I'd love to see the two-parameter delegate opApply used in lieu of one-parameter if the later is lacking... * non-ref foreach currently uses ref delegates without propagating writes back into the opApply body; if this implicit copy removed the const() (where allowed by the typing rules) the fail_on_write struct would work (for some index types). * each of the six foreach types (v;A) (ref v;A) (i,v;A) (ref i,v;A) (i,ref v;A) (ref i, ref v;A) could create a different delegate signature, so that a fully foreach-enabled struct has six more-or-less identical opApply methods with slightly different parameters.

*** This issue has been marked as a duplicate of issue 6652 ***