-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Warn when using to_owned on already owned types #6715
Comments
Good idea.
Yes 👍 We can call the lint |
@rustbot claim I think I've got something mostly working for this, but I am not sure if I am doing anything the proper way, or if there is a better way to go about this. I have a few hangups with the "Additional Comments" -- and I still need to figure out how to handle |
@anall Feel free to ask questions on Zulip or open a work in progress PR. Converting to snake case is not the right approach. Instead there should be a list of known "to owned" functions that are equivalent to |
Re the "Additional comments", as far as I can tell with a really rough heuristic-filtered grep, these are the types in the standard library that have a "to_type" method (ignoring Owned which trips my heuristic given how the trait is set up):
|
I like the idea of replacing |
I would just keep |
What it does
By virtue of deferencing to
&[T]
, Vec implements several methods such as.to_owned()
or.to_vec()
. When called on Vec, these methods do the same thing as.clone()
, all the while being more confusing ("why call to_owned or to_vec on something that already is a Vec and is owned?")Categories
style
What is the advantage of the recommended code over the original code
As mentioned above,
to_vec
andto_owned
are potentially misleading and confusing when used on Vec.clone
is a clearer alternative.Drawbacks
None.
Example
Could be written as:
Additional comments
Same applies to String with
.to_owned()
and.to_string()
. Or PathBuf with.to_owned()
andto_path_buf()
. Or I suppose CString with.to_owned()
. There's a lot of these cases in the standard library actually. Should those cases be handled using the same lint?The text was updated successfully, but these errors were encountered: