Thankfully no one writes that today because String::from is objectively superior
-
This Tweet is unavailable.
-
This Tweet is unavailable.
-
-
Replying to @Gankra_ @withoutboats
Isn't there still a holy war over that vs str.to_owned()?
3 replies 0 retweets 2 likes -
Replying to @sgrif @withoutboats
I'm in the "I was around before 1.0 where we changed the name of String twice and fucked with to_owned a million times and had to refactor from to_owned to to_string back to to_owned and now I hate ownerifying strings in any way period strings can go die in a fire" camp
3 replies 0 retweets 9 likes -
Replying to @ManishEarth @withoutboats
I'm mostly just mad that it's `&str` and not `&String`. I don't care about the capacity, let the compiler deal with getting rid of that
1 reply 0 retweets 0 likes -
Yeah but &String is more like &(&str, capacity) so even if you don't care about the capacity you still have double indirection.
1 reply 0 retweets 0 likes -
We really could go all in on the autoderef train and start silently applying it to stuff like that at the type level. Not that I think it's a good idea, but it is interesting to think about.
1 reply 0 retweets 0 likes -
Good luck actually getting the semantics right :P. If you don't guarantee anything pointer-wise then *maybe* you can pass &T where T: Freeze as T itself. *maybe*. Sounds very scary even if potentially optimization-y.
1 reply 0 retweets 1 like
Plus wouldn't actually removing str summon one of the old ones?
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.