RangeFrom, Part 2..: What I think is wrong about the design

In December 2025, James Munns made a post about how RangeFrom just wraps around when it reaches the end. This led to the author forming several opinions and thoughts about it, which they want to share in this article. The article covers the properties people might expect from a RangeFrom iterator and demonstrates why they are incorrect.

For example, an iterator like let mut iter = (n..) would be expected to yield values from n onwards. However, the implementation detail of incrementing the internal counter before yielding the value means that overflow checking causes the iterator to overflow before yielding the final value (u8::MAX). The final value will then be the penultimate value before the overflow, which prints 253 and 254 and panics if overflow checks are enabled. If overflow checks are not enabled, it prints 255, and the iterator runs in an infinite loop.

The author's main issue with the current design is that RangeFrom behaves unexpectedly and breaks the concept of a range being something like [n, +∞). This inconsistency can be problematic, as it requires extra care when using RangeFrom as a guard for values. The only way to avoid this is by using n..={Integer}::MAX. However, this approach is not ideal for most types.

Types such as char, std::ascii::Char, Ipv4Addr, and Ipv6Addr do not follow the suggested behaviour but instead panics, wraps, or saturates when overflow occurs. The standard library inconsistently handles these types, with some panicking while others saturate or wrap. The author suggests documenting these behaviors and proposes adding an enumerate_with method to the Iterator trait to provide a more consistent and user-friendly solution.