refactor: refactor some unnecessary clone and use next_back to make clippy happy #5554
Conversation
…lippy happy Signed-off-by: yihong0618 <[email protected]>
| @@ -157,7 +157,7 @@ pub fn get_basename(path: &str) -> &str { | |||
| if !path.ends_with('/') { | |||
| return path | |||
| .split('/') | |||
| .last() | |||
| .next_back() | |||
There was a problem hiding this comment.
Nice catch! However, it's a bit harder to understand compared to last(). Would you consider adding a comment to explain it?
There was a problem hiding this comment.
of course will add it
There was a problem hiding this comment.
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.
Signed-off-by: yihong0618 <[email protected]>
|
will change all the |
Next maybe I can do this, do I need to open an issue? |
This patch do not close any issues, just drop some un necessary clone to make a little better performance
and only check the
corefor now, if it is useful will check all others dir in separate pull requestWhich issue does this PR close?
Closes #.
This patch do not close anything
Rationale for this change
no Rationale for this change
What changes are included in this PR?
using static check to understand if we can drop some clone, and found 4 of them,
Are there any user-facing changes?
No