Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFC: New range types for Edition 2024 #3550

Merged
merged 10 commits into from
May 20, 2024
Prev Previous commit
Next Next commit
legacy types as iterators for new types would break convention
pitaj committed Dec 29, 2023
commit bf83d5b3e63e47b7a898ae2746995f03ab26e9b1
2 changes: 1 addition & 1 deletion text/3550-new-range.md
Original file line number Diff line number Diff line change
@@ -390,7 +390,7 @@ We believe that it is best to keep the `Range` naming for several reasons:

We could choose to make `new_range.into_iter()` resolve to a legacy range type. This would reduce the number of new types we need to add to the standard library.

But the legacy range types have a much larger API surface than other `Iterator`s in the standard library, which typically only implement the various iterator traits and maybe have a `remainder` method. This can reduce optimization potential for the iterators, possibly limiting performance.
But the legacy range types have a much larger API surface than other `Iterator`s in the standard library, which typically only implement the various iterator traits and maybe have a `remainder` method. Using the legacy range types this way would break convention and could reduce optimization potential for the iterators, possibly limiting performance.

# Prior art
[prior-art]: #prior-art