Clippy lints / Complexity
Clippy lint · Complexity · checked with Clippy 0.1.99
clippy::get_last_with_len: accessing last element with `x.get(x.len() - 1)`
What it meansChecks for usage of x.get(x.len() - 1) instead of x.last(). It is in the complexity group and warns by default.
What you see
warning: accessing last element with `x.get(x.len() - 1)` --> main.rs:4:20 | 4 | let last_element = x.get(x.len() - 1); | ^^^^^^^^^^^^^^^^^^ help: try: `x.last()` | = help: for further information visit https://rust-lang.github.io/rust-clippy/stable/index.html#get_last_with_len = note: `#[warn(clippy::get_last_with_len)]` on by default
Real output of Clippy 0.1.99 (Rust 1.99) on the example below. Names and line numbers in yours will differ.
Does it matter?
Using x.last() is easier to read and has the same result. Note that using x[x.len() - 1] is semantically different from x.last(). Indexing into the array will panic on out-of-bounds accesses, while x.get() and x.last() will return None. There is another lint (get_unwrap) that covers the case of using x.get(index).unwrap() instead of x[index].
Code that does something simple in a complicated way. Warns by default.
How to fix it
Clippy can fix this one for you: run cargo clippy --fix (add --allow-dirty if you have uncommitted changes). Review the diff before you commit.
Flagged
let x = vec![2, 3, 5];
let last_element = x.get(x.len() - 1);
Write this instead
let x = vec![2, 3, 5];
let last_element = x.last();
Turn it off, or on
Allow it where it does not fit your code, as narrowly as you can:
On one item
#[allow(clippy::get_last_with_len)]
fn my_function() { /* ... */ }Whole crate (Cargo.toml)
[lints.clippy]
get_last_with_len = "allow"One run
cargo clippy -- -A clippy::get-last-with-lenThe [lints] table needs Rust 1.74 or newer. In a workspace, put it under [workspace.lints.clippy] and add [lints] workspace = true to each member.
Clippy's own documentation
What it does
Checks for usage of x.get(x.len() - 1) instead of
x.last().
Why is this bad?
Using x.last() is easier to read and has the same
result.
Note that using x[x.len() - 1] is semantically different from
x.last(). Indexing into the array will panic on out-of-bounds
accesses, while x.get() and x.last() will return None.
There is another lint (get_unwrap) that covers the case of using
x.get(index).unwrap() instead of x[index].
Example
let x = vec![2, 3, 5];
let last_element = x.get(x.len() - 1);
Use instead:
let x = vec![2, 3, 5];
let last_element = x.last();
From the Clippy lint list (0.1.99), part of the Rust project, MIT or Apache-2.0. Official entry.
Related lints
- too_many_argumentsChecks for functions with too many parameters
- clone_on_copyusing `clone` on type `u64` which implements the `Copy` trait
- type_complexityChecks for types used in structs, parameters and let declarations above a certain complexity threshold
- filter_map_identityChecks for usage of filter_map(|x| x)
- filter_nextChecks for usage of _.filter(_).next()
- flat_map_identityChecks for usage of flat_map(|x| x)
- identity_opChecks for identity operations, e.g., x + 0
- implied_bounds_in_implsLooks for bounds in impl Trait in return position that are implied by other bounds. This can happen when a trait is specified that another trait already has as a supertrait (e.g
- inspect_for_eachcalled `inspect(..).for_each(..)` on an `Iterator`
All 847 Clippy lints · Rust compiler errors · Cargo.toml checker
Up next
Related lintclippy::too_many_argumentsChecks for functions with too many parametersRead it next →Did this answer your question?