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.

Sign up for GitHub

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

Jump to bottom

Tracking Issue for RFC 3550: New range types #123741

Open
1 of 20 tasks
traviscross opened this issue Apr 10, 2024 · 13 comments
Open
1 of 20 tasks

Tracking Issue for RFC 3550: New range types #123741

traviscross opened this issue Apr 10, 2024 · 13 comments
Assignees
@pitaj
Labels
A-maybe-future-edition Something we may consider for a future edition. B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. F-new_range `#![feature(new_range)]` S-tracking-impl-incomplete Status: The implementation is incomplete. S-tracking-needs-documentation Status: Needs documentation. S-tracking-needs-migration-lint Status: This item needs a migration lint. S-tracking-unimplemented Status: The feature has not been implemented. T-lang Relevant to the language team, which will review and decide on the PR/issue. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.

Comments

@traviscross
Copy link
Contributor

traviscross commented Apr 10, 2024 •
edited
Loading

This is a tracking issue for the RFC 3550: New range types

The feature gate for the issue is #![feature(new_range)].

Tracking issue for the library change:

About tracking issues

Tracking issues are used to record the overall progress of implementation. They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions. A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature. Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

Steps

Unresolved Questions

  • Will the migration cost make this feasible for either Rust 2024 or Rust 2027?
  • How do we properly document and execute the ecosystem transition?
  • How much time will it take to propagate this change throughout the ecosystem?
  • What degree of ecosystem saturation would we be satisfied with?
  • How much time do we need with stable library types before making the lang change?
  • What about libraries that wish to maintain a certain MSRV?
  • Taking into account all of the mitigations (diagnostics, migrations, and lints but NOT language-level changes), is the level of ecosystem disruption acceptable?
  • What is expected of new libraries? Should they continue to support both sets of ranges or only the new ones?
  • Will new Rust users need to learn about older editions because of downstream users of their code?
  • "Would #[cfg(overflow_checks)] just magically work?" (see here).

Related

cc @pitaj
@traviscross traviscross added C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. T-lang Relevant to the language team, which will review and decide on the PR/issue. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. A-edition-2024 Area: The 2024 edition labels Apr 10, 2024
@pitaj pitaj self-assigned this Apr 11, 2024
@traviscross traviscross mentioned this issue May 20, 2024
Merged
@traviscross traviscross added S-tracking-impl-incomplete Status: The implementation is incomplete. S-tracking-unimplemented Status: The feature has not been implemented. S-tracking-needs-migration-lint Status: This item needs a migration lint. S-tracking-needs-documentation Status: Needs documentation. B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. labels May 21, 2024
@orlp
Copy link
Contributor

orlp commented May 26, 2024 •
edited
Loading

To see which iterator methods we may want to add to the new ranges, I did an informal search on
Github using the following query:

language:rust NOT is:fork /\W\s*\(\s*\w*\s*\.\.=?\s*\w*\s*\)\s*.\s*method\s*\(/

I matched on anything that looks like ( <> .. <> ) or ( <> ..= <> ) that is not immediately
preceded by some identifier character, to avoid matching things like vec.drain(..).map(_).

Example for map: search.

This isn't perfect but captures a rough amount of usage. Just looking by the number of matches:

  • map: 65.8k
  • rev: 23.2k
  • collect: 9.9k
  • for_each: 8.5k
  • step_by: 8.3k
  • filter: 8.2k
  • flat_map: 4.2k
  • fold: 3.5k
  • zip: 3.4k
  • filter_map: 1.6k
  • find: 1.5k
  • chain: 1.4k
  • take_while: 1.1k
  • all: 1.1k
  • cycle: 0.7k
  • enumerate: 0.6k
  • scan: 0.4k
  • product: 0.4k
  • find_map: 0.3k
  • any: 0.3k
  • sum: 0.2k
  • take: 0.2k
  • skip: 0.1k
  • try_*: 0.1k
  • min*: 0.1k
  • max*: 0.1k
  • map_while: 0.1k
  • position: 0.1k
  • skip_while: 0.1k
  • count: 0.1k
  • reduce: 0.1k
  • nth: 0.1k
  • unzip: 0

I personally think filter is a decent cut-off, which gives the inherent methods map, rev, collect, for_each, step_by, filter.

@pitaj

This comment was marked as resolved.

Sign in to view
@orlp
Copy link
Contributor

orlp commented May 26, 2024 •
edited
Loading

@pitaj Nope, just a clerical error. I fixed it.

@programmerjake

This comment was marked as resolved.

Sign in to view
@orlp

This comment was marked as resolved.

Sign in to view
@programmerjake

This comment was marked as resolved.

Sign in to view
@orlp

This comment was marked as resolved.

Sign in to view
@pitaj

This comment was marked as resolved.

Sign in to view
@orlp

This comment was marked as resolved.

Sign in to view
@traviscross traviscross mentioned this issue May 26, 2024
Open
@traviscross
Copy link
Contributor Author

Let's continue that discussion about which methods to add in a separate issue here rather than on the tracking issue.

@traviscross traviscross added the F-new_range `#![feature(new_range)]` label May 27, 2024
@pitaj pitaj mentioned this issue May 28, 2024
Open
12 tasks
@traviscross traviscross mentioned this issue May 30, 2024
Merged
@traviscross traviscross added the S-tracking-at-risk Status: This item is at risk of missing e.g. edition deadlines. label Jun 18, 2024
@kennytm kennytm mentioned this issue Jun 26, 2024
Open
workingjubilee added a commit to workingjubilee/rustc that referenced this issue Jul 6, 2024
@workingjubilee
Rollup merge of rust-lang#125751 - pitaj:new_range_api, r=jhpratt
9c8a889 
Add `new_range_api` for RFC 3550

Initial implementation for rust-lang#125687

This includes a `From<legacy::RangeInclusive> for RangeInclusive` impl for convenience, instead of the `TryFrom` impl from the RFC. Having `From` is highly convenient and the debug assert should find almost all misuses.

This includes re-exports of all existing `Range` types under `core::range`, plus the range-related traits (`RangeBounds`, `Step`, `OneSidedRange`) and the `Bound` enum.

Currently the iterators are just wrappers around the old range types.

Tracking issues:

- rust-lang#123741
- rust-lang#125687
rust-timer added a commit to rust-lang-ci/rust that referenced this issue Jul 6, 2024
@rust-timer
Unrolled build for rust-lang#125751
b87f1bd 
Rollup merge of rust-lang#125751 - pitaj:new_range_api, r=jhpratt

Add `new_range_api` for RFC 3550

Initial implementation for rust-lang#125687

This includes a `From<legacy::RangeInclusive> for RangeInclusive` impl for convenience, instead of the `TryFrom` impl from the RFC. Having `From` is highly convenient and the debug assert should find almost all misuses.

This includes re-exports of all existing `Range` types under `core::range`, plus the range-related traits (`RangeBounds`, `Step`, `OneSidedRange`) and the `Bound` enum.

Currently the iterators are just wrappers around the old range types.

Tracking issues:

- rust-lang#123741
- rust-lang#125687
@traviscross
Copy link
Contributor Author

@rustbot labels -A-edition-2024 +A-maybe-future-edition -S-tracking-at-risk

This is, unfortunately, not likely to have all the pieces in place in time to ship with the Rust 2024 edition, so we're going to drop the label.

Thanks to all those who have been working on this, and we hope to see this ship in a future edition.

@rustbot rustbot added A-maybe-future-edition Something we may consider for a future edition. and removed A-edition-2024 Area: The 2024 edition S-tracking-at-risk Status: This item is at risk of missing e.g. edition deadlines. labels Jul 29, 2024
@GrigorenkoPV
Copy link
Contributor

This is, unfortunately, not likely to have all the pieces in place in time to ship with the Rust 2024 edition, so we're going to drop the label.

What things are missing so far?

@traviscross
Copy link
Contributor Author

What things are missing so far?

See the issue description above. We need to check off all of those boxes in order to land this in any edition.

@antonilol antonilol mentioned this issue Aug 11, 2024
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@pitaj pitaj

Labels
A-maybe-future-edition Something we may consider for a future edition. B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. F-new_range `#![feature(new_range)]` S-tracking-impl-incomplete Status: The implementation is incomplete. S-tracking-needs-documentation Status: Needs documentation. S-tracking-needs-migration-lint Status: This item needs a migration lint. S-tracking-unimplemented Status: The feature has not been implemented. T-lang Relevant to the language team, which will review and decide on the PR/issue. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@orlp @pitaj @traviscross @programmerjake @rustbot @GrigorenkoPV