refactor: refactor some unnecessary clone and use next_back to make clippy happy#5554
refactor: refactor some unnecessary clone and use next_back to make clippy happy#5554Xuanwo merged 2 commits intoapache:mainfrom yihong0618:hy/refactor_some_clone
Conversation
…lippy happy Signed-off-by: yihong0618 <[email protected]>
Xuanwo
left a comment
There was a problem hiding this comment.
Thank you @yihong0618 for polishing this!
| 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 |
Xuanwo
left a comment
There was a problem hiding this comment.
Thank you @yihong0618 for this!
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