4 ms·

Rust apparently got relatively close to not having &str as a primitive type and instead only providing a library alias to &[u8] when Rust 1.0 shipped. Score an

Rust apparently got relatively close to not having &str as a primitive type and instead only providing a library alias to &[u8] when Rust 1.0 shipped. Score another for Rust's Safety Culture. It would be convenient to just have &str as an alias for &[u8] but if that mistake had been allowed all the safety checking that Rust now does centrally has to be owned by every single user forever. Instead of a few dozen checks overseen by experts there'd be myriad sprinkled across every project and always ready to bite you.

adastra22 1y ago
. (early morning brain fart -- I need my coffee)
- tialaramex 1y ago
  So it's true that technically the primitive type is str, and indeed it's even possible to make a &mut str though it's quite rare that you'd want to mutably borrow the string slice. However no &str is not "an alias for &&String" and I can't quite imagine how you'd think that. String doesn't exist in Rust's core, it's from alloc and thus wouldn't be available if you don't have an allocator.
  - zozbot234 1y ago
    str is not really a "primitive type", it only exists abstractly as an argument to type constructors - treating the & operator as a "type constructor" for that purpose, but including Box<>, Rc<>, Arc<> etc. So you can have Box<str> or Arc<str> in addition to &str or perhaps &mut str, but not really 'str' in isolation.
inferiorhuman 1y ago
Even so you end up with paper cuts like len which returns the number of bytes.
- toast0 1y ago
  The problem with string length is there's probably at least four concepts that could conceivably be called length, and few people are happy when none of them are len. Of the top of my head, in order of likely difficulty to calculate: byte length, number of code points, number of grapheme/characters, height/width to display. Maybe it would be best for Str not to have len at all. It could have bytes, code_points, graphemes. And every use would be precise.
  - inferiorhuman 1y ago
    Problems arise when you try to take a slice of a string and end up picking an index (perhaps based on length) that would split a code point. String/str offers an abstraction over Unicode scalars (code points) via the chars iterator, but it all feels a bit messy to have the byte based abstraction more or less be the default. FWIW the docs indicate that working with grapheme clusters will never end up in the standard library.
    - toast0 1y ago
      > but it all feels a bit messy to have the byte based abstraction more or less be the default. I mean, really neither should be the default. You should have to pick chars or bytes on use, but I don't think that's palatable; most languages have chosen one or the other as the preferred form. Or some have the joy of being forward thinking in the 90s and built around UCS-2 and later extended to UTF-16, so you've got 16-bit 'characters' with some code points that are two characters. Of course, dealing with operating systems means dealing with whatever they have as well as what the language prefers (or, as discussed elsewhere in this thread, pretending it doesn't exist to make easy things easier and hard things harder)
    - xyzzyz 1y ago
      You can easily treat `&str` as bytes, just call `.as_bytes()`, and you get `&[u8]`, no questions asked. The reason why you don't want to treat &str as just bytes by default is that it's almost always a wrong thing to do. Moreover, it's the worst kind of a wrong thing, because it actually works correctly 99% of the time, so you might not even realize you have a bug until much too late. If your API takes &str, and tries to do byte-based indexing, it should almost certainly be taking &[u8] instead.
steveklabnik 1y ago
It wouldn't have been an alias, it would have been struct Str([u8]). Nothing would have been different about the safety story. https://github.com/rust-lang/rfcs/issues/2692 https://github.com/rust-lang/rfcs/issues/2692
- stouset 1y ago
  I love this kind of historical knowledge. Thanks for sharing it!

adastra22 1y ago

. (early morning brain fart -- I need my coffee)

tialaramex 1y ago
So it's true that technically the primitive type is str, and indeed it's even possible to make a &mut str though it's quite rare that you'd want to mutably borrow the string slice. However no &str is not "an alias for &&String" and I can't quite imagine how you'd think that. String doesn't exist in Rust's core, it's from alloc and thus wouldn't be available if you don't have an allocator.
- zozbot234 1y ago
  str is not really a "primitive type", it only exists abstractly as an argument to type constructors - treating the & operator as a "type constructor" for that purpose, but including Box<>, Rc<>, Arc<> etc. So you can have Box<str> or Arc<str> in addition to &str or perhaps &mut str, but not really 'str' in isolation.

inferiorhuman 1y ago

Even so you end up with paper cuts like len which returns the number of bytes.

toast0 1y ago
The problem with string length is there's probably at least four concepts that could conceivably be called length, and few people are happy when none of them are len. Of the top of my head, in order of likely difficulty to calculate: byte length, number of code points, number of grapheme/characters, height/width to display. Maybe it would be best for Str not to have len at all. It could have bytes, code_points, graphemes. And every use would be precise.
- inferiorhuman 1y ago
  Problems arise when you try to take a slice of a string and end up picking an index (perhaps based on length) that would split a code point. String/str offers an abstraction over Unicode scalars (code points) via the chars iterator, but it all feels a bit messy to have the byte based abstraction more or less be the default. FWIW the docs indicate that working with grapheme clusters will never end up in the standard library.
  - toast0 1y ago
    > but it all feels a bit messy to have the byte based abstraction more or less be the default. I mean, really neither should be the default. You should have to pick chars or bytes on use, but I don't think that's palatable; most languages have chosen one or the other as the preferred form. Or some have the joy of being forward thinking in the 90s and built around UCS-2 and later extended to UTF-16, so you've got 16-bit 'characters' with some code points that are two characters. Of course, dealing with operating systems means dealing with whatever they have as well as what the language prefers (or, as discussed elsewhere in this thread, pretending it doesn't exist to make easy things easier and hard things harder)
  - xyzzyz 1y ago
    You can easily treat `&str` as bytes, just call `.as_bytes()`, and you get `&[u8]`, no questions asked. The reason why you don't want to treat &str as just bytes by default is that it's almost always a wrong thing to do. Moreover, it's the worst kind of a wrong thing, because it actually works correctly 99% of the time, so you might not even realize you have a bug until much too late. If your API takes &str, and tries to do byte-based indexing, it should almost certainly be taking &[u8] instead.

steveklabnik 1y ago

It wouldn't have been an alias, it would have been struct Str([u8]). Nothing would have been different about the safety story. https://github.com/rust-lang/rfcs/issues/2692 https://github.com/rust-lang/rfcs/issues/2692

stouset 1y ago
I love this kind of historical knowledge. Thanks for sharing it!