Tracking Issue for RFC 3550: New range types · Issue #123741 · rust-lang/rust (original) (raw)

Skip to content

Navigation Menu

• • GitHub Copilot Write better code with AI
  • GitHub Advanced Security Find and fix vulnerabilities
  • Actions Automate any workflow
  • Codespaces Instant dev environments
  • Issues Plan and track work
  • Code Review Manage code changes
  • Discussions Collaborate outside of code
  • Code Search Find more, search less
• Explore
  • Learning Pathways
  • Events & Webinars
  • Ebooks & Whitepapers
  • Customer Stories
  • Partners
  • Executive Insights
• • GitHub Sponsors Fund open source developers
  • The ReadME Project GitHub community articles
• • Enterprise platform AI-powered developer platform
• Pricing

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Sign up

Description

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

• RFC: New range types for Edition 2024 rfcs#3550

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

Tracking issue for the library change:

• Tracking Issue for new_range_api (part of RFC 3550) #125687

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

• Implement new types in nightly.
  • Add new_range_api for RFC 3550 #125751
• Stabilize new range types (in all editions).
• Implement lang changes in nightly as an unstable feature. Implement unstable new_range feature #136167
• Enable lang changes in nightly for new edition.
• Implement migration lints.
• Crater run the lang changes and migration lints.
• Stabilize lang changes for new edition.
• Add documentation to the dev guide.
  • See the instructions.
• Add documentation to the reference.
  • See the instructions.
• Add documentation to the edition guide.
• N/A: Add formatting for new syntax to the style guide.
  • See the nightly style procedure.
• Ensure ready for release of new edition.

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

• Tracking Issue for new_range_api (part of RFC 3550) #125687
• Add new_range_api for RFC 3550 #125751

cc @pitaj