4 ms·

In C, strings can hold invalid unicode. However, in Rust a str is guaranteed to be valid utf-8. For added confusion, Rust has a `char` type which is actually 3

• Animats 6y ago
  let s = "hello world".to_string(); for ch in s.chars() { print!({},ch); } will iterate through a string character by character. That's the most common use of the "char" type - one at a a time, not arrays of them. Although the proper grapheme form is: use unicode_segmentation::UnicodeSegmentation; // 1.7.1 let s = "hello world".to_string(); for gr in UnicodeSegmentation::graphemes(s.as_str(), true) { print!("{}", gr) } This will handle accented characters and emoji modifiers. A line break in the middle of a grapheme will mess up output. By the way, open season for proposing new emoji starts tomorrow.[1] [1] http://blog.unicode.org/2020/09/emoji-150-submissions-re-open-april-2.html http://blog.unicode.org/2020/09/emoji-150-submissions-re-ope...
  • TheGrassyKnoll 6y ago
    Thanks for the code snippet, however (kind of a Rust newbie here) $ cargo install unicode_segmentation (chokes) $ cargo install unicode-segmentation (seems to work) and in Cargo.toml [dependencies] unicode-segmentation = "1.7.1" (seems to work) yet in the code, its: use unicode_segmentation::UnicodeSegmentation; Why couldn't they be consistent using a dash vs. an underscore ?
    • steveklabnik 6y ago
      You don’t cargo install libraries; the cargo.toml line is the right thing. You can’t use -s in Rust identifiers, so they need to be normalized to _ to be referred to in code.
    • estebank 6y ago
      Identifiers in Rust can't have dashes (rustc will never rely on whitespace for proper tokenization). It is arguable that because of that crates should not have dashes in their name. cargo was changed to automatically convert dashes to underscores for convenience because some dislike underscores in names. I personally think this is an unnecessary source of confusion and now I would make all tools (mainly cargo) treat them interchangeably.
      • a1369209993 6y ago
        > rustc will never rely on whitespace for proper tokenization Huh? That seems clearly untrue, eg `fnfoo` vs `fn foo` or `x && y` vs `x & &y` or `x<<shift_or_type > ::foo` vs `x < <shift_or_type>::foo`? Presumably for some or all of those, one version ends up being a error (eg bitwise and with a pointer from `x & &y` probably doesn't work), but that's not at the level of tokenization.
        • ChrisSD 6y ago
          Given the context, I think they simply mean that a-b is interpreted the same as a - b. It can't be interpreted as a single identifier.
    • deleted 6y ago
      [deleted]
    • mvolfik 6y ago
      this is way too common in Python world too - packages (crates) use dashes (they look nicer?), but the packaged library is named with underscores, because `-` is math operation and can't be in a name