Tracking issue for `..=` inclusive ranges (RFC #1192) -- originally `...`

[nikomatsakis]

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
  • Initial mentoring instructions on writing the PR can be found here.
• Documentation
  • Book Document inclusive ranges as a new feature. book#1134
  • Reference Document inclusive ranges. reference#215
  • Rust-by-example Document inclusive ranges. rust-by-example#1015
• 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 for start, end and new methods of RangeInclusive #49022 on this feature.

[JohanLarsson]

Maybe a..b| or a..b]

[bakirov]

I think this will open up the way for the new kind of unpredictable errors in future because of a simple typo (.. vs ...). Better if it was .... (4 periods). This way it is less error-prone to the human factor, imo.

[canndrew]

I think rust-lang/rfcs#1592 and rust-lang/rfcs#1582 combined make a case for using the ..= syntax instead. Unless someone can think of better syntax than (head..., tail) for expanding a tuple at the front of a larger tuple.

[kornelski]

I've found this issue because I had off-by-one-dot error in my code when I've meant to use exclusive range.

👎 for the ... syntax. I think having an easy-to-mistype syntax that causes off-by-one errors would be a footgun.

The functionality is useful though, so I'd be happy to have it with a different syntax, e.g. ..=