-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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.
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
assigning_clones
complains about static str
-> String
assignment.
#12799
Comments
Is this not more efficient though, as |
Yes, there may be an efficiency gain, but the suggested change hurts the code readability a lot. I can't imagine trying to teach a new Rust progammer to use Additionally, in some cases (e.g. |
FWIW, this lint was recently moved to pedantic (allow-by-default) for that reason. See also #12778 (and linked issues/PRs). I'm not sure what can be done here though now that it's in pedantic. Pedantic lints are ones that when you do blanket- The lint is not wrong here. It could be more efficient when the string has enough capacity. So when someone enables this lint and wants to be warned by it, I imagine they would also like to be warned for |
I don't know if it's too late but we might be able to beta-nominate/backport the category change PR so that it makes it into 1.79. If it doesn't get beta backported, it will stay warn-by-default until 1.80 most likely (which is in two months). |
Summary
The
assigning_clones
lint fires when I assign to aString
using aconst &str
and.to_owned()
.The suggested replacement is harder to read and obfuscates the meaning of the code.
Lint Name
assigning_clones
Reproducer
I tried this code:
I saw this happen:
I expected to see this happen:
Nothing.
Version
Additional Labels
No response
The text was updated successfully, but these errors were encountered: