20051, "bradcray", "Do we have the wrong behavior currently for loops over 'zip(1.., expr)'? (zipped unbounded ranges)", "2022-06-21T20:40:49Z"
While writing some code last week, I was surprised to find that a loop like:
for (i,j) in zip(1.., 1..5) do
writeln((i,j));
currently loops five times then stops without complaint. My expectation was that it would loop five times and then complain of a size mismatch between the two iterands. Specifically, Chapel generally complains about size mismatches in serial loops (and tries to in parallel loops, though it's unsuccessful in some cases, noted in issue #11428); and it seems that it ought to be complaining in this case as well.
In the parallel zippered case, we've traditionally given unbounded ranges special "can conform to anything" semantics, which permit loops like:
forall (a, i) in zip(my1dArray, 0..) do ...
and we've discussed extending leader-follower iterators to permit users to write their own "conforming" iterators, though that has not yet been implemented. For that reason, it does not surprise me that:
for (i,j) in zip(1..5, 1..) do
would run five times then terminate without complaint, but I would expect that if an unbounded range is in the first/leader position of the zip() that the loop would be conceptually infinite. Note that this can be useful in cases where the loop contains a break/return/exit, as in this (toy) example:
for (i,j) in zip(0.., genRandNums()) {
if j == 0.5 {
writeln("Got 0.5 on iteration ", i);
break;
}
}
This issue asks whether we've made a mistake here, or whether there's some rationale for the current behavior that I'm missing.