It'd be a bummer and pretty annoying to lose the performance IMO. When I started using Rust, "don't use to_string, it's slow" was a common correction, sort of like how "always take &str as an arg, not &String" still is. Over time that went away, which is presumably also why use of to_string became so common. This would basically be a step backwards to needing that correction.
I actually didn't remember what the explicit correction was when I started writing this comment, only that there were right and wrong ways to go from literals to Strings. I didn't remember because I haven't had to for years -- I stopped caring when I was explicitly told or read somewhere there was no longer a penalty! I'm certain I've since used to_string where I "shouldn't have" (and wouldn't have), if it had always remained slow.
Looks like this was the announcement...
One method,
to_string, comes from a generic API which was previously relatively slow, while the customto_ownedimplementation provided better performance. Using specialization, these two functions are now equivalent.
...and in the PR someone said...
Cool!
to the ".to_string()" is slow memes!
and clippy deprecated the lint against to_string (though it was later restored as a pedantic lint (not due to performance concerns)).