RangeFrom, Part 1․․

While working on a Clippy lint, the author began to question the implementations of the RangeFrom type. To express their thoughts, they decided to write a post about the history and design of the RangeFrom type, as well as their opinions on its future. The post will be divided into two parts: the first will cover the type's history, and the second will discuss the author's design thoughts and opinions.

The RangeFrom type was introduced for slicing in RFC0198, implemented in rust#17318. This was followed by RFC0439 (started on 2014-11-03), which made significant changes to the cmp and ops modules, including the addition of ranges as actual types. The implementation of these changes is tracked in rust#19148, and the development began on 2014-12-13 when contributor @nrc wrote that he would implement ranges and indexing using ranges.

Following the discussion on using range notation, the pull request adding the new range types (rust#19858) was created, implementing the RangeFrom type in core. One notable aspect of this implementation is the deliberate overflow handling, which causes the iterator to panic before yielding the last value when overflow checks are enabled.

After the implementation of the RangeFrom type, an issue was opened (#20249) addressing boundary concerns in the Step trait. The discussion concluded that an open-ended interval should repeat indefinitely, rather than being bounded by the maximum. However, the responsibility for handling overflow would remain with the end-user, resulting in a panic if the maximum integer is reached.

In 2015, issue rust#25696 was opened, discussing the overflow behavior of the RangeFrom type. This issue was later closed by a pull request (#32592) that added a note about overflow to the documentation. The pull request was made in response to a Reddit question, where users explained the behavior and concluded that overflowing is the responsibility of the end-user.

A few years later, in 2020, a pull request (#72368) was made to amend the overflow note, stabilizing it and preventing any future changes. The note now clearly informs users that overflow behavior is user-defined and will cause a panic in the default debug profile.

In November 2023, an API Change Proposal (ACP) was opened (libs-team#304), addressing the overflow behavior of RangeFrom. As of now, no consensus has been reached regarding changes to this behavior. In the same month, a pre-RFC titled "Fixing Range by 2027" was opened, proposing to fix issues with range types, including their Copy trait and the direct implementation of the iterator on Range* types. Most of the comments in the thread revolve around these two main issues.