Dogfood {exclusive,half-open} ranges in compiler (nfc) #78244
Conversation
|
r? @varkor (rust_highfive has picked a reviewer for you, use r? to override) |
rust-highfive
added
the
S-waiting-on-review
compiler/rustc_lint/src/unused.rs
Outdated
| @@ -251,7 +251,7 @@ impl<'tcx> LateLintPass<'tcx> for UnusedResults { | |||
| } | |||
| ty::Array(ty, len) => match len.try_eval_usize(cx.tcx, cx.param_env) { | |||
| // If the array is definitely non-empty, we can do `#[must_use]` checking. | |||
| Some(n) if n != 0 => { | |||
| Some(n @ 1..) => { | |||
There was a problem hiding this comment.
This is quite cute, but I'm not sure it's more readable. I'd like to hear what others think.
There was a problem hiding this comment.
My overall hypothesis was that this pattern is neither significantly more or less legible to humans, but significantly more legible to the compiler, which allows it to better reason around and assist the programmer, so in the spirit of meeting the machine halfway...
I will note my initial inclination was to move the simple "negative" ( Some(0) | None ) condition first, which might make more sense. Happy to hear what others think, though.
There was a problem hiding this comment.
hmm, I think I would prefer to exhaustively match by starting with Some(0) | None => false, Some(n).
It might still make sense to use Some(n @ 1..) as a quick reminder to the programmer, but in general I don't have a strong opinion here
compiler/rustc_lint/src/unused.rs
Outdated
| @@ -251,7 +251,7 @@ impl<'tcx> LateLintPass<'tcx> for UnusedResults { | |||
| } | |||
| ty::Array(ty, len) => match len.try_eval_usize(cx.tcx, cx.param_env) { | |||
| // If the array is definitely non-empty, we can do `#[must_use]` checking. | |||
| Some(n) if n != 0 => { | |||
| Some(n @ 1..) => { | |||
There was a problem hiding this comment.
hmm, I think I would prefer to exhaustively match by starting with Some(0) | None => false, Some(n).
It might still make sense to use Some(n @ 1..) as a quick reminder to the programmer, but in general I don't have a strong opinion here
jyn514
added
F-exclusive_range_pattern
|
Updated to put the Some(0) | None first. |
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.
workingjubilee
force-pushed
the
dogfood-fancy-ranges
branch
from
f637d33 to
0e88db7
Compare
|
Thanks! @bors r+ rollup |
|
📌 Commit 0e88db7 has been approved by |
bors
added
S-waiting-on-bors
…as-schievink Rollup of 11 pull requests Successful merges: - rust-lang#75078 (Improve documentation for slice strip_* functions) - rust-lang#76138 (Explain fully qualified syntax for `Rc` and `Arc`) - rust-lang#78244 (Dogfood {exclusive,half-open} ranges in compiler (nfc)) - rust-lang#78422 (Do not ICE on invalid input) - rust-lang#78423 (rustc_span: improve bounds checks in byte_pos_to_line_and_col) - rust-lang#78431 (Prefer new associated numeric consts in float error messages) - rust-lang#78462 (Use unwrapDIPtr because the Scope may be null.) - rust-lang#78493 (Update cargo) - rust-lang#78499 (Prevent String::retain from creating non-utf8 strings when abusing panic) - rust-lang#78505 (Update Clippy - temporary_cstring_as_ptr deprecation) - rust-lang#78527 (Fix some more typos) Failed merges: r? `@ghost`
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.