It does not really matter in rust anyway: literals are &’static str so naturally immutable and essentially free, and mutable strings require jumping hoops to share, so it’s hard to unwittingly have one mutate from under you.
There is also &mut str. The nice thing about Rust is that the same memory area can be used as a "StringBuilder" with &mut str, and then as a "String" with &str. Once you have a &str reference, Rust statically guarantees that no one else cam mutate it.
You can't really do anything useful with a `&mut str`. For example, you can't change the length of the string or any characters in the string (without unsafe code). The latter is perhaps surprising, but it's because strings in Rust are always UTF-8, so changing a logical character could imply changing the length of the string, and changing a byte could result in invalid UTF-8.
All of those languages except JavaScript have mutable strings; they just have different names and API shapes. Python has io.StringIO, Java has StringBuilder, Rust has String. (JavaScript has less need for this because JavaScript strings are ropes in most widely used implementations, reducing the overhead of concatenation, though the language spec doesn't require this.)
By your incredible criteria of things being mutable strings if they behave nothing like strings but can produce one, JavaScript absolutely does have a mutable string, it’s called Array. It’s also a mutable integer.
I don't consider JavaScript's Array to count because using it as a mutable string incurs a significant amount of additional overhead, because it has to box every character and check at runtime the type of each element. This is not true of the APIs that I listed.
It does not really matter in rust anyway: literals are &’static str so naturally immutable and essentially free, and mutable strings require jumping hoops to share, so it’s hard to unwittingly have one mutate from under you.
Rust the language has one string type: &str
The standard library also has String, CString, CStr, OsString, and OsStr.
The latter four are for niche situations. 99.9% of the time, it's similar to Java: &str is Java's String, String is Java's StringBuffer/StringBuilder.
99.9% of the time rust has 1 string type. The other 0.1% of the time it has 99, got it.
It has two, not 99, with owned and borrowed pairs.
There is also &mut str. The nice thing about Rust is that the same memory area can be used as a "StringBuilder" with &mut str, and then as a "String" with &str. Once you have a &str reference, Rust statically guarantees that no one else cam mutate it.
You can't really do anything useful with a `&mut str`. For example, you can't change the length of the string or any characters in the string (without unsafe code). The latter is perhaps surprising, but it's because strings in Rust are always UTF-8, so changing a logical character could imply changing the length of the string, and changing a byte could result in invalid UTF-8.
1 reply →
Yeah the type is really just str but I didn’t want to get into it. &mut str is kinda weird.
I would add Path and PathBuf to that list.
Paths are not strings, that's the whole point!
1 reply →
Rust has one core String type.
These are just the language semantics.
The other string types are non-Rust strings. Filesystem, C strings, etc. You only deal with them in dealing with specific OS and binding interfaces.
95% of the time you'll just be using String.
All of those languages except JavaScript have mutable strings; they just have different names and API shapes. Python has io.StringIO, Java has StringBuilder, Rust has String. (JavaScript has less need for this because JavaScript strings are ropes in most widely used implementations, reducing the overhead of concatenation, though the language spec doesn't require this.)
By your incredible criteria of things being mutable strings if they behave nothing like strings but can produce one, JavaScript absolutely does have a mutable string, it’s called Array. It’s also a mutable integer.
I don't consider JavaScript's Array to count because using it as a mutable string incurs a significant amount of additional overhead, because it has to box every character and check at runtime the type of each element. This is not true of the APIs that I listed.