| Age | Commit message (Collapse) | Author | Lines |
|
|
|
Stabilize or_patterns (RFC 2535, 2530, 2175)
closes #54883
This PR stabilizes the or_patterns feature in Rust 1.53.
This is blocked on the following (in order):
- [x] The crater run in https://github.com/rust-lang/rust/pull/78935#issuecomment-731564021
- [x] The resolution of the unresolved questions and a second crater run (https://github.com/rust-lang/rust/pull/78935#issuecomment-735412705)
- It looks like we will need to pursue some sort of edition-based transition for `:pat`.
- [x] Nomination and discussion by T-lang
- [x] Implement new behavior for `:pat` based on consensus (https://github.com/rust-lang/rust/pull/80100).
- [ ] An FCP on stabilization
EDIT: Stabilization report is in https://github.com/rust-lang/rust/pull/79278#issuecomment-772815177
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
In particular, this allows us to write more explicit matches that
avoid the pitfalls of using a fully general fall-through case, yet
remain fairly ergonomic. Less logic is in guard cases, more is in
the actual exhaustive case analysis.
No functional changes.
|
|
|
|
|
|
use `array_windows` instead of `windows` in the compiler
I do think these changes are beautiful, but do have to admit that using type inference for the window length
can easily be confusing. This seems like a general issue with const generics, where inferring constants adds an additional
complexity which users have to learn and keep in mind.
|
|
|
|
|
|
|
|
|