| > That's not the problem. There absolutely should be two different types (and I don't even care that the names are so poor). But half the rust APIs take one type and the other take another (even when the string isn't manipulated or stored in any way, shape, or form). Some interfaces are only implemented for string and others only for &str. Things which are implemented for Strings are those which actually require it. String derefs to &str so you can call any &str method on String, any trait implemented by &str is basically implemented by String, and if you need to pass &str and have a String you just &v. > Deciding between two distinct types &str and &string (not mut &string) for your function's interface is nonsense. There are very very few reasons to ever ask for an &String but then what, should the language somehow forbid regular references to a perfectly standard type? > It makes no sense to have to _decide_ between which two views of a string that you can read-but-not-manipulate you want to use &String is not a view of anything, it's a regular reference to a string living somewhere in memory. > A constant reference to a string should automatically decompose into a view of that string and that should be that. It does that if a function asks for an &str and you &s where s:String. All Rust doesn't do is remove &String from the language, in the same way string is a valid C++ construct. > Additionally, that dereferencing a string returns a pointer... that makes no sense. Dereferencing a String doesn't return a pointer. String is* a pointer, so you can deref' it to get the str behind it (which is not a pointer, it's the actual unsized string data). |