-
Notifications
You must be signed in to change notification settings - Fork 13.6k
Closed
Labels
B-RFC-implementedBlocker: Approved by a merged RFC and implemented but not stabilized.Blocker: Approved by a merged RFC and implemented but not stabilized.B-unstableBlocker: Implemented in the nightly compiler and unstable.Blocker: Implemented in the nightly compiler and unstable.C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFCCategory: An issue tracking the progress of sth. like the implementation of an RFCE-mentorCall for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion.Call for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion.T-langRelevant to the language teamRelevant to the language teamT-libs-apiRelevant to the library API team, which will review and decide on the PR/issue.Relevant to the library API team, which will review and decide on the PR/issue.disposition-mergeThis issue / PR is in PFCP or FCP with a disposition to merge it.This issue / PR is in PFCP or FCP with a disposition to merge it.finished-final-comment-periodThe final comment period is finished for this PR / Issue.The final comment period is finished for this PR / Issue.
Description
Current status
We are planning to to change the syntax for inclusive ranges and patterns to ..=
. The ...
syntax in patterns is stable and will remain (silently) deprecated for the time being; rustfmt can rewrite ...
to ..=
. This comes after much discussion. See this comment for justification.
No more syntax discussion should be had in this thread. Any different proposals of exclusive range syntax should take place on the user's forum or internals forum, after you have read all existing comments and their rationale here. Notably, breaking backwards compatibility is a non-starter.
Steps to take
- Initial implementation
- Change to accept
..=
as synonym for...
in patterns and to accept..=
in expressions Initial support for..=
syntax #44709 - Documentation
- Make RangeInclusive just a two-field struct (amend 1192) rfcs#1980 proposed a tweak to
RangeInclusive
- Stabilization Stabilize inclusive range (
..=
) #47813- Note: The fields of
RangeInclusive
have been left out from this round of stabilization. Please track Tracking issue forstart
,end
andnew
methods of RangeInclusive #49022 on this feature.
- Note: The fields of
tengwar, duesee, tshepang, omarkj, trolley813 and 20 moreEricQAQ, 3442853561, huangjj27, biluohc, kamyuentse and 3 moreUtherII, tjkirch, m0n0chr0m3, stanislav-tkach, samoylovfp and 3 more
Metadata
Metadata
Assignees
Labels
B-RFC-implementedBlocker: Approved by a merged RFC and implemented but not stabilized.Blocker: Approved by a merged RFC and implemented but not stabilized.B-unstableBlocker: Implemented in the nightly compiler and unstable.Blocker: Implemented in the nightly compiler and unstable.C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFCCategory: An issue tracking the progress of sth. like the implementation of an RFCE-mentorCall for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion.Call for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion.T-langRelevant to the language teamRelevant to the language teamT-libs-apiRelevant to the library API team, which will review and decide on the PR/issue.Relevant to the library API team, which will review and decide on the PR/issue.disposition-mergeThis issue / PR is in PFCP or FCP with a disposition to merge it.This issue / PR is in PFCP or FCP with a disposition to merge it.finished-final-comment-periodThe final comment period is finished for this PR / Issue.The final comment period is finished for this PR / Issue.