For the same reason that Borrow and Clone aren't ToBorrow and ToCloned.
It should just be Own
then, you could create strings with "my static str".own(), and nobody would complain about "to_owned" or "to_string" anymore too
Are you familiar with the existing conventions around to_, as_, into_?
In that framework, to_ is the correct naming choice.
5 Likes
By that logic Clone should be ToCloned and Borrow should be AsBorrowed, no?
What I'm saying is that regardless of these conventions, ToOwned::to_owned has unnecessary morphology that could just as easily be conveyed with Own::own
It follows the logic of the Clone naming. The trait is a verb that you can do to a value.
I think that as_, to_, and into_ are useful when converting between different types, such as IntoIterator (but even then, why not Iterate, vec.iterate()). But it especially doesn't make sense when converting between representations of the same type
1 Like
And I want to reinforce that I'd much rather write "whatever".own() than "whatever".to_owned()
Do you have a specific outcome you'd like to see here? Or are you venting?
8 Likes
Ah, I'm venting about naming. I doubt such a refactor would ever get merged. I just wanted to see if anyone had similar thoughts, guess it's just me.
2 Likes
Isn't the problem with to_owned and to_string the fact that they are two ways to do the same thing? (3 if you count into, 4 with clone if you're "converting" a &String to a String)
If to_owned was named own this situation would remain the same.
They are only the same thing for strings. For non-string types to_string would convert it to a string, while to_owned would create an owned non-string value.
2 Likes
No? Neither clone nor borrow consume self.
If anything, clone and borrow fit with a different naming pattern: as_Y(&X).
But "as" in Rust is used for cheap, trivial conversions from a borrowed type into another borrowed type, like AsRef, as in the already linked API guideline (Naming - Rust API Guidelines)
Clone is really a "to" operation in the sense conveyed by the table in the guideline (borrowed -> owned, expensive). It could indeed be called ToClone, like Borrow could be called AsBorrow
1 Like
I was going to say they aren't the same thing, but as I was writing a test case showing that, it turned out they are. And the reason is far from obvious to the casual reader because the documentation is misleading, unfortunately. It only shows impl<T> ToString for T where T: Display + ?Sized, and hides the fact that there are many specializations, one of which is for &str, where the implementation ... uses to_owned. If rustdoc ignores specializations, at least the text should probably say something about these.
1 Like
The specializations are not intended to be covered by the stability guarantees of the standard library, which is why they are not documented as such. Stabilization (even min_specialization) is still an unstable feature.
3 Likes
Sure, but the fact that to_string is explicitly not using Display for strings is an important detail that should be highlighted somewhere. I was actually avoiding to_string on string slices because I thought it was using Display.
1 Like
Why does it matter how is it being written?
Using Display has significantly more overhead. Compiler Explorer
2 Likes
"Don't use to_string, use to_owned instead" was a common correction before the specialization.
3 Likes
My thinking is that to_owned is the best current alternative. static_string.to_string() is silly, to_owned shows you're creating an owned type from a borrowed one
If it was shorter, it would probably be more likely to be used, and it would be easier to argue it is better than to_string. it could become the canonical way to get a String from a &str
neither does ToOwned consume self
My point is that ToCloned and AsBorrowed are dumb names. The concept is just as easily, if not better, conveyed by just Clone and Borrow
using verbs for single-function traits seems like the best way to go about this. the function should be the verb that's happening to the value
Of course this isn't always possible, but having to prefix things with To because of "convention" is as dumb as prefixing interfaces with I
1 Like
You might find these URLO posts interesting: