RangeFrom, Part 1․․

The `RangeFrom` type in Rust (`n..`) was implemented to iterate indefinitely by overflowing the index type. This design choice was made early in Rust’s development, with the rationale that an unbounded range should behave like a C-style `for` loop. The implementation uses the `Step` trait, which was introduced alongside `RangeFrom` and remains unstable. The decision to overflow was intentional, but the lack of preserved IRC logs means the full context of the trade-offs is lost to time.

A concrete consequence of this design is that `RangeFrom` panics when overflow checks are enabled and the index reaches its maximum value. For example, iterating over `255u8..` will panic before yielding `255`, even though the range is conceptually unbounded. This creates a mismatch between the mathematical definition of an unbounded range and its practical behavior in Rust. Engineers who assume `RangeFrom` will always yield values up to `MAX` may encounter unexpected crashes or incomplete sequences.

The post highlights that this behavior was not universally agreed upon at the time. Some contributors argued for bounding `RangeFrom` to `MAX` instead of overflowing, but the majority favored the infinite iteration model. The discussion resurfaced in later issues, such as rust#25708, where the practical implications of overflow checks became apparent. This suggests that the design may not have fully anticipated how `RangeFrom` would interact with Rust’s evolving safety guarantees.

For engineers, the key takeaway is that `RangeFrom` is not a drop-in replacement for unbounded iteration in all cases. If your code relies on iterating up to the limits of an integer type, you may need to manually handle edge cases or use alternative constructs. The post also sets the stage for a follow-up discussion on potential changes to `RangeFrom`, which could lead to new lint warnings or even RFCs to revisit its behavior. Until then, the current implementation remains a footgun for those unaware of its quirks.