3 ms·
Functions that index into the string-considered-as-a-sequence-of-characters can be meaningful, and sometimes useful, in cases where you know that the string con
by mjw1007 4y ago
Functions that index into the string-considered-as-a-sequence-of-characters can be meaningful, and sometimes useful, in cases where you know that the string contains only characters from some simple restricted subset.
(You might know that "by construction", or by checking.)
In a language like Rust which doesn't directly support refinement types, it's common to end up using the standard str or String types in cases where you know such a thing.
So I think there are times when that sort of indexing function would be sensible.
A common example is when you're working with a very restricted subset of printable ASCII (things like stock codes, ISBNs, EANs). Or not so long ago I was working with 64-character-long strings containing only U+0020 and U+2654 ..= U+265F .
- kazinator 4y ago> in cases where you know that the string contains only characters from some simple restricted subset But I'm saying, even in cases where you don't! A string function that works with byte characters, written before Unicode existed, can do useful processing on UTF-8 data which contains characters that didn't exist when that code was written.
- mjw1007 4y agoThat's true, but in most of those cases you don't need to be able to use numeric character-count-based indexes into the string (which is what the article is arguing that you don't need). You'd typically be happy if the parsing function that you're using to find the location of (say) each comma in the string gives you an opaque token for each such location, with a way to use those tokens to get slices of the string back. So in practice we can use byte offsets into a UTF-8 string as those tokens, while the programmer doesn't really have to care that that's what they are.