we currently have an assumption that iterators are reversible, but I think that was a mistake in hindsight. Some custom iterators simply aren't (e.g. an infinite range), or have terrible performance if you reverse them (e.g. a linked list), and I think it's better to just expose things like List.iter_rev from only the data structures that can reasonably offer reversed iterators, instead of having the reversal operation in Iter itself.
(I haven't landed his change yet, but I'll be opening a PR for it soon.)
This did indeed break a few exercises, I'm fixing them now.
One use-case was: (1..=10).rev() which no longer works.
It would be nice to have a simple way to express this. For now, I've replaced this with List.from_iter(1..=10).iter_rev(). It works, but it materializes a List when we don't really need one.
A few random ideas:
10..>1 (but only works with exclusive ranges and step -1)10..=1 by -110..-1..1 (F# style) or maybe 10..[-1]..110, 9, ..=1 (Haskell-style)However, none of these fix the fact that these ranges should be reversible.
1..=10 could produce a Range type. You would have to add iter() or rev_iter() to actually get an Iter, example: (1..=10).iter() to get 1 to 10. Might be a good compromise actually. It would also allow things like (1..=10).step(2).iter_rev() to get 10, 8, 6, 4, 2.Also, (1..=10).size_hint() could return Known(10) (currently it returns Unknown).
Aurélien Geron said:
perhaps
1..=10could produce aRangetype. You would have to additer()orrev_iter()to actually get anIter, example:(1..=10).iter()to get 1 to 10. Might be a good compromise actually. It would also allow things like(1..=10).step(2).iter_rev()to get 10, 8, 6, 4, 2.Also,
(1..=10).size_hint()could returnKnown(10)(currently it returnsUnknown).
yeah, that all seems reasonable! We could put it under Num.Range so it doesn't need a separate top-level thing
and since for works on anything that has an iter method, Range would continue to Just Work inside for loops
Oh right, I had forgotten about that last point, cool. :+1:
@Aurélien Geron want to make a GH Issue for this?
Sure, I'm on it
https://github.com/roc-lang/roc/issues/10753
Note: this change broke roc-random, so this PR fixes it.
I'll wait for tomorrow's nightly and then bump that and kickoff CI and a release
This roc-random? https://github.com/kili-ilo/roc-random
yes, the latest nightly doesn't have the Iter thing does it?
Ah yes, indeed
I had another PR staged to update the nightly, but then I realised it didn't have the fix in it
Btw, something seems to be broken with types, see this new issue.
I also ran into a type issue while fixing roc-random: I had to add a type spec for component_generator on line 278 in package/Random.roc`, or else it ran into a type issue.
this will be a good regression test to add when we fix that
Aurélien Geron said:
I also ran into a type issue while fixing
roc-random: I had to add a type spec forcomponent_generatoron line 278 in package/Random.roc`, or else it ran into a type issue.
Do you think you could make a minimal repro? I guess it's probably ok to make an issue with the git commits from roc-random, but would be nice if we had something small we could convert into a regression test
I'll give it a shot.
Last updated: Sep 03 2026 at 15:16 UTC