Skip to content

chore: change str_ref_to_string to str_ref_to_owned #12796

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

Merged
merged 1 commit into from
Jul 18, 2022
Merged

chore: change str_ref_to_string to str_ref_to_owned #12796

merged 1 commit into from
Jul 18, 2022

Conversation

mmirate
Copy link
Contributor

@mmirate mmirate commented Jul 18, 2022

ToString is implemented by many different types than &str, and represents a serialization into string data. The fact that said data is returned as owned, is an implementation detail resulting from the lack of a parameter for a pre-allocated buffer.

If merely copying borrowed string data to owned string data is all that is desired, ToOwned is a much better choice, because if the user later refactors the code such that the input is no longer an &str, then they will get a compiler error instead of a mysterious runtime-behavioral change.

ToString is implemented by many different types than &str, and
represents a serialization into string data. The fact that said data is
returned as owned, is an implementation detail.

If merely copying borrowed string data to owned string data is all that
is desired, ToOwned is a much better choice, because if the user later
refactors the code such that the input is no longer an `&str`, then they
will get a compiler error instead of a mysterious change-in-behavior.
@Veykril
Copy link
Member

Veykril commented Jul 18, 2022

Usually what people use here is subjective (there are too many ways to go from str to String really), but I like your refactor argument a lot here, so let's go with to_owned 👍
Thanks
@bors r+

@bors
Copy link
Contributor

bors commented Jul 18, 2022

📌 Commit be30c4d has been approved by Veykril

It is now in the queue for this repository.

@bors
Copy link
Contributor

bors commented Jul 18, 2022

⌛ Testing commit be30c4d with merge 567a5e9...

@bors
Copy link
Contributor

bors commented Jul 18, 2022

☀️ Test successful - checks-actions
Approved by: Veykril
Pushing 567a5e9 to master...

@bors bors merged commit 567a5e9 into rust-lang:master Jul 18, 2022
@mmirate mmirate deleted the patch-1 branch July 18, 2022 22:39
@ChayimFriedman2
Copy link
Contributor

ChayimFriedman2 commented Jul 19, 2022

What about a setting to choose the preferred way (String::from(), .into(), .to_owned() or .to_string())? I can send a PR if appropriate.

@Veykril
Copy link
Member

Veykril commented Jul 19, 2022

A setting just for this seems very very specific. I am not opposed to having configurability here, but I'd rather we find something that applies more generically to these kinds of things than just for this specific diagnostic.

@mmirate
Copy link
Contributor Author

mmirate commented Jul 19, 2022

What about a setting to choose the preferred way (String::from(), .into(), .to_owned() or .to_string())? I can send a PR if appropriate.

ToOwned is the correct color for this here bike shed, for reasons described in the PR description, and, more eloquently, for this reason:

I feel like to_owned and into would be better options than to_string here. to_string means, essentially, "convert to the String that Display::fmt would give me". For &str, this happens to be the same as converting to an owned String, but that seems like a happy coincidence. to_owned and into are more explicit about the nature of the transformation taking place.

@ChayimFriedman2
Copy link
Contributor

ToOwned is the correct color for this here bike shed

I do agree, but some people still prefer other methods, and I don't think rust-analyzer should force people to change their workflow. But I'm fine with not changing that :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants