Stabilize inclusive range (..=)

[kennytm]

Stabilize the followings:

• inclusive_range — The std::ops::RangeInclusive and std::ops::RangeInclusiveTo types, except its fields (tracked by Tracking issue for start, end and new methods of RangeInclusive #49022 separately).
• inclusive_range_syntax — The a..=b and ..=b expression syntax
• dotdoteq_in_patterns — Using a..=b in a pattern

cc #28237
r? @rust-lang/lang

[kennytm]

dotdoteq_in_patterns is included because the corresponding documentation PRs already mentioned it... If it turns out to be too early to stabilize I can take it out.

[leonardo-m]

See also: #45222

[kennytm]

@leonardo-m The performance fix can be done independently from the stabilization I believe.

[bluss]

Performance might depend on the data fields available, stabilizing public fields in the range inclusive iterator is restricting possibilities (to be factual).

Having them not be iterators (but iterable) is an alternative, but the drawbacks of that are pretty clear from the original rust-lang/rfcs#1192, so it is not a good idea.

[nikomatsakis]

The only way that it might be relevant is if we decided to change so that ..= doesn't implement Iterator but only IntoIterator. I've historically been mega-opposed, on the grounds that .. and ..= should behave as similarly as possible, but if that's truly needed for perf or something that might be persuasive... (I've no idea if that is part of #45222 or what)

[shepmaster]

r? @withoutboats

[shepmaster]

r? @nrc

[nrc]

I think we need documentation before we can stabilise things nowadays, and according to the tracking issue we don't have any of that.

[kennytm]

@nrc:

• Book: Document inclusive ranges as a new feature. book#1134
• Reference: Document inclusive ranges. reference#215
• RBE: Document inclusive ranges. rust-by-example#1015

The book and reference say they want to wait until stabilization, so are we entering deadlock 😂.

[steveklabnik]

The book and reference say they want to wait until stabilization, so are we entering deadlock 😂.

Usually, the book and reference need a PR open, and then the stuff gets stabilized, and then they get merged. So we're still good :)

[nrc]

@bors: r+

Thanks for the links!

[bors]

📌 Commit 570ffb2 has been approved by nrc

[bors]

🔒 Merge conflict

[bors]

☔ The latest upstream changes (presumably #47998) made this pull request unmergeable. Please resolve the merge conflicts.

[kennytm]

Fixed merge conflict.

Should this need any FCP? #28237 didn't go through a stabilization FCP yet.

[kdy1]

Inclusive range syntax causes panic when it's passed to attribute proc macro (actually an ICE, but rustc lies)

alexcrichton/futures-await#55

---

Edit: It doesn't matter because the issue is already reported. (#47950, I searched with proc macro range, but couldn't find)

[kennytm]

@kdy1 This issue has been filed as #47950.

[nikomatsakis]

I would be in favor of stabilizing, but I think we do need an FCP.

@kennytm if you want to push this through, do you think you could write up a summary comment on the tracking issue #28237 ? In particular, I would like to see:

• Major features we expect to work, and the tests that we have for those in the code base
• Pointers to the docs (at least pending)
• Anything else that seems relevant

The idea is that people with minimal context should be able to quickly see what is being stabilized. It is not meant to rehash every argument (in particular, I don't think we have to go into the tortured history of choosing a particular sigil here).

[bors]

☔ The latest upstream changes (presumably #48017) made this pull request unmergeable. Please resolve the merge conflicts.

[bors]

📌 Commit 939cfa2 has been approved by petrochenkov

[bors]

⌛ Testing commit 939cfa2 with merge 5c375d69d2f600668849c42c9c7ba880bc38eefb...

[bors]

💔 Test failed - status-travis

[kennytm]

@bors retry #43283

[01:33:27] test sync::mpsc::tests::stress_recv_timeout_two_threads ... ok
[01:33:31] test collections::hash::map::test_map::test_lots_of_insertions ... ok
[01:33:53] test process::tests::test_process_output_fail_to_start ... test process::tests::test_process_output_fail_to_start has been running for over 60 seconds


No output has been received in the last 30m0s, this potentially indicates a stalled build or something wrong with the build itself.
Check the details on how to adjust your build configuration on: https://docs.travis-ci.com/user/common-build-problems/#Build-times-out-because-no-output-was-received

The build has been terminated

[bors]

⌛ Testing commit 939cfa2 with merge 3926453...

[bors]

☀️ Test successful - status-appveyor, status-travis
Approved by: nrc
Pushing 3926453 to master...

[jadbox]

is there docs for this?

[shepmaster]

@jadbox do you mean like https://doc.rust-lang.org/std/ops/struct.RangeInclusive.html ? Those have been around for a while now.