Comment by inferiorhuman
1 day ago
If your API takes &str, and tries to do byte-based indexing, it should
almost certainly be taking &[u8] instead.
Str is indexed by bytes. That's the issue.
1 day ago
If your API takes &str, and tries to do byte-based indexing, it should
almost certainly be taking &[u8] instead.
Str is indexed by bytes. That's the issue.
As a matter of fact, you cannot do
You will get a compiler error telling you that you cannot index into &str.
Right, you have to give it a usize range. And that will index by bytes. This:
compiles and prints out "1".
This:
compiles and panics with the following error:
To get the nth char (scalar codepoint):
To get a substring:
To actually get the bytes you'd have to call #as_bytes which works with scalar and range indices, e.g.:
IMO it's less intuitive than it should be but still less bad than e.g. Go's two types of nil because it will fail in a visible manner.
It's actually somewhat hard to hit that panic in a realistic scenario. This is because you are unlikely to be using slice indices that are not on a character boundary. Where would you even get them from? All the standard library functions will return byte indices on a character boundary. For example, if you try to do something like slice the string between first occurrence of character 'a', and of character 'z', you'll do something like
and it will never panic, because find will never return something that's not on a char boundary.
1 reply →