Skip to content

Lint using next_back when last is more appropriate #1822

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
clarfonthey opened this issue Jun 10, 2017 · 1 comment
Open

Lint using next_back when last is more appropriate #1822

clarfonthey opened this issue Jun 10, 2017 · 1 comment
Labels
A-lint Area: New lints E-medium Call for participation: Medium difficulty level problem and requires some initial experience. T-middle Type: Probably requires verifiying types

Comments

@clarfonthey
Copy link

clarfonthey commented Jun 10, 2017 •
edited
Loading

It makes sense to lint the use of next_back in cases where the iterator is not used beyond the call to next_back, suggesting to replace last instead. Additionally, implementations of Iterator::last that only delegate to next_back should be suggested to be removed.

This will likely need to be special cased to only do this for iterators which are known to optimise last into next_back through some sort of whitelist.
@mcarton mcarton added E-medium Call for participation: Medium difficulty level problem and requires some initial experience. A-lint Area: New lints T-middle Type: Probably requires verifiying types labels Jun 10, 2017
@KamilaBorowska
Copy link
Contributor

KamilaBorowska commented Sep 11, 2022 •
edited
Loading

I think I would rather go the other way around, warning about last when iterator implements DoubleEndedIterator. The problem with last is that it doesn't require DoubleEndedIterator to be implemented which means that in general case it's going to be slow, and while this can be dealt with manual implementation of that method, most iterators in standard library don't bother to do so. For those that do bother, I don't expect any particular difference between next_back and last even when the iterator is to be immediately dropped.

Jakobeha added a commit to Jakobeha/enquote that referenced this issue May 3, 2024
@Jakobeha
replace chars().last() chars().next_back()
4cc8d88 
idk if it makes a difference optimized, but the former theoretically traverses the entire string, while the latter doesn't. Semantically they're the exact same. Also see rust-lang/rust-clippy#1822, it doesn't seem like this is well-known.
Jakobeha added a commit to Jakobeha/enquote that referenced this issue May 3, 2024
@Jakobeha
replace chars().last() chars().next_back()
9d50cae 
Idk if it makes a difference optimized, but the former theoretically traverses the entire string, while the latter doesn't. Semantically they're the exact same. Also see rust-lang/rust-clippy#1822, it doesn't seem like this is well-known.
@qsantos qsantos mentioned this issue Jan 1, 2025
Merged
github-merge-queue bot pushed a commit that referenced this issue Jan 2, 2025
@Manishearth
Add lint for calling Iterator::last() on DoubleEndedIterator (#13922
631d9a2 
)

I [recently realized that `.last()` might not call `next_back()` when it
is
available](https://qsantos.fr/2025/01/01/rust-gotcha-last-on-doubleendediterator/).
Although the implementor could make sure to implement `last()` to do so,
this is not what will happen by default. As a result, I think it is
useful to add a lint to promote using `.next_back()` over `.last()` on
`DoubleEndedIterator`.

If this is merged, we might want to close #1822.

changelog: [`double_ended_iterator_last`]: Add lint for calling
`Iterator::last()` on `DoubleEndedIterator`
@yihong0618 yihong0618 mentioned this issue Jan 16, 2025
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
A-lint Area: New lints E-medium Call for participation: Medium difficulty level problem and requires some initial experience. T-middle Type: Probably requires verifiying types
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@KamilaBorowska @mcarton @clarfonthey