4 ms·

According to the article, Rust does the same thing - "<emoji>".len() == 17.

by Mawr 3y ago

adastra22 3y ago
"<emoji>".chars().count() == 5 Rust gives you the freedom to specify what you mean.
- tialaramex 3y ago
  Sure, however that's actually decoding the string into Unicode scalar values, and then counting them whereas the length of the string is a direct property of the string reference (it's a fat pointer [address + length]) I don't remember, but I think the size hint is set on the Chars iterator, so it can see it has 17 bytes of data, it knows that can't encode more than 17 Unicode scalar values, nor can it encode fewer than five. But since we ask for an exact count that hint is unused, the actual decoding will take place.
  - adastra22 3y ago
    Yes, your point? That is the same thing which happens in Swift if you request the length of a string and it gives you the number of glyphs (1, in this case). Rust doesn't take sides here. It exposes all the different ways you might want to calculate the "length" of a string, and lets you pick which one you mean. The non-zero-cost choices involve a multi-step specification (like `.chars().count()`), which states explicitly the calculation involved.
    - tialaramex 3y ago
      Asking str.len() is a single very cheap operation, it's not only O(1) in the sense you'd learn in an algorithms course, it's really actually very cheap to do, it's fine if an algorithm relies heavily on str.len() In contrast chars().count() creates an iterator and runs the iterator to completion counting steps, that's O(N) for a string of length N, and is in practice very expensive, you should definitely cache this value if you will need it repeatedly. It is possible the compiler can see what you're doing and cache it, but I am very far from certain so you should do so explicitly. This is important in contrast to say, C, where strlen(str) is O(N) because it doesn't have fat pointers and so it has no idea how long the string is in any sense.
- ttlsa 3y ago
  len([]rune("<emoji>")) does the same thing in Go.
- insanitybit 3y ago
  Yeah but unfortunately it provides `.len()` directly. It's documented to make clear that it's the bytecount and not the characters, and that humans usually work with characters, but given that this isn't even a trait implementation I think `.as_bytes().len()` or something would have been better.

According to the article, Rust does the same thing - "<emoji>".len() == 17.

by Mawr 3y ago

According to the article, Rust does the same thing - "<emoji>".len() == 17.

adastra22 3y ago

"<emoji>".chars().count() == 5 Rust gives you the freedom to specify what you mean.

tialaramex 3y ago
Sure, however that's actually decoding the string into Unicode scalar values, and then counting them whereas the length of the string is a direct property of the string reference (it's a fat pointer [address + length]) I don't remember, but I think the size hint is set on the Chars iterator, so it can see it has 17 bytes of data, it knows that can't encode more than 17 Unicode scalar values, nor can it encode fewer than five. But since we ask for an exact count that hint is unused, the actual decoding will take place.
- adastra22 3y ago
  Yes, your point? That is the same thing which happens in Swift if you request the length of a string and it gives you the number of glyphs (1, in this case). Rust doesn't take sides here. It exposes all the different ways you might want to calculate the "length" of a string, and lets you pick which one you mean. The non-zero-cost choices involve a multi-step specification (like `.chars().count()`), which states explicitly the calculation involved.
  - tialaramex 3y ago
    Asking str.len() is a single very cheap operation, it's not only O(1) in the sense you'd learn in an algorithms course, it's really actually very cheap to do, it's fine if an algorithm relies heavily on str.len() In contrast chars().count() creates an iterator and runs the iterator to completion counting steps, that's O(N) for a string of length N, and is in practice very expensive, you should definitely cache this value if you will need it repeatedly. It is possible the compiler can see what you're doing and cache it, but I am very far from certain so you should do so explicitly. This is important in contrast to say, C, where strlen(str) is O(N) because it doesn't have fat pointers and so it has no idea how long the string is in any sense.
ttlsa 3y ago
len([]rune("<emoji>")) does the same thing in Go.
insanitybit 3y ago
Yeah but unfortunately it provides `.len()` directly. It's documented to make clear that it's the bytecount and not the characters, and that humans usually work with characters, but given that this isn't even a trait implementation I think `.as_bytes().len()` or something would have been better.