In Scala, in particular, types are not the assigned type like in C (where they also serve as the storage specification) -- they are assertions, that the compiler will check are compatible with the code.
So `val x: int = "hello"` is no good and the compiler can cut it short right there; this is especially useful as call-site documentation.
It's also the case that there are plenty of languages where all types imply storage specification and they support plenty of type elision.
let x = 5i32;
What do you mean? For string literals you just do
let foo= "bar";
and that's it.
BTW, in Rust you can omit most variable type annotations since the compiler is able to infer them. You have to give type annotations to functions though.
let foo= "bar".to_string();
It's on purpose though, because Rust likes to make heap allocations explicit, and I find it fine to be honest, but you mileage may vary.
> 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
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.