281
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 02 Oct 2023
281 points (96.1% liked)
Programming
17314 readers
231 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 2 years ago
MODERATORS
Minor, but I'm not sure this is as unambiguous as the article claims. It's true that for someone "that isn’t burdened with computer internals" that this is the most obvious "length" of the string, but programmers are by definition burdened with computer internals. That's not to say the length shouldn't be 1 though, it's more that the "length" field/property has a terrible name, and asking for the length of a string is a very ambiguous question to begin with.
Instead, I think a better solution is to be clear what length you're actually referring to. For example, with Rust, the
.len()
method documents itself as the number of bytes in the string and warns that it may not be what you're interested in. Similarly,.chars()
clarifies that it iterates over Unicode Scalar Values, and not grapheme clusters (and that grapheme clusters are unfortunately not handled by the standard library).For most high level applications, I think you generally do want to work with grapheme clusters, and what Swift does makes sense (assuming you can also iterate over the individual bytes somehow for low level operations). As long as it is clearly documented what your "length" refers to, and assuming the other lengths can be calculated, I think any reasonably useful length is valid.
The article they link in that section does cover a lot of the nuances between them, and is a great read for more discussion around what the length should be.
Edit: I should also add that Korean, for example, adds some additional complexity to it. For example, what's the string length of 각? Is it 1, because it visually consumes a single "space"? Or is it 3 because it's 3 letters (ㄱ, ㅏ, ㄱ)? Swift says the length is 1.
If we're being really pedantic, the last part in Korean is counted with different units:
So we could have separate implementations of length() where we count such cases with different criteria... But I wouldn't expect non-speakers of Korean know all of this.
Plus, what about Chinese characters? Are we supposed to count 人 as one but 仁 as one (character) or two (radicals)? It gets only more complicated.