rust-lang / rust-lang/rust

Tracking Issue for RFC 3550: New range types

Open
#123,741 15 comments 35 reactions 1 assignee View on GitHub

@pitaj is already working on this.

Since Apr 11, 2024.

A-maybe-future-edition B-RFC-approved C-tracking-issue F-new_range S-tracking-impl-incomplete S-tracking-needs-documentation S-tracking-needs-migration-lint S-tracking-unimplemented T-lang T-libs
Dominant language
Rust
Stars
119k
Forks
16.1k
PR merge metrics
PR metrics pending

Description

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

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.