3 ms·

https://users.rust-lang.org/t/to-string-vs-to-owned-for-string-literals/1441 https://users.rust-lang.org/t/to-string-vs-to-owned-for-stri... > I’m more fond of

https://users.rust-lang.org/t/to-string-vs-to-owned-for-string-literals/1441 https://users.rust-lang.org/t/to-string-vs-to-owned-for-stri... > I’m more fond of using .into(). It requires adding type hints in some cases, but for most cases it is shorter than the alternatives. Especially when passing a string literal to a function that requires String. > Now that specialization for str::to_string() has landed, we can safely say that to_string() has the same performance as to_owned(), and thus to_string() should be used since it’s more clear > I now strongly prefer to_owned() for string literals over either of to_string() or into(). yay language complexity

littlestymaar 7y ago
> yay language complexity You could argue that Rust strings are complex, because they are : having 8 "string-like" types (owned strings vs string slices (references), cstr/cstring, path and pathbuf, osstr/osString) is complex, but having three different methods doing exactly the same thing isn't. Yes it's redundant, but what would you rather have : str as the only easily convertible type with no to_string method? Or the only reference type without to_owned? No ability to use into for strings while it works everywhere else? Obviously, redundancy is better than theses alternatives.