• Black616Angel@feddit.de
    link
    fedilink
    arrow-up
    11
    ·
    1 year ago

    And rust also has the “🤦”.chars().count() which returns 1.

    I would rather argue that rust should not have a simple len function for strings, but since str is only a byte slice it works that way.

    Also also the len function clearly states:

    This length is in bytes, not chars or graphemes. In other words, it might not be what a human considers the length of the string.

    • lemmyvore@feddit.nl
      link
      fedilink
      English
      arrow-up
      9
      ·
      1 year ago

      None of these languages should have generic len() or size() for strings, come to think of it. It should always be something explicit like bytes() or chars() or graphemes(). But they’re there for legacy reasons.

      • Djehngo@lemmy.world
        link
        fedilink
        arrow-up
        6
        ·
        1 year ago

        Makes sense, the code-points split is stable; meaning it’s fine to put in the standard library, the grapheme split changes every year so the volatility is probably better off in a crate.

        • Knusper@feddit.de
          link
          fedilink
          arrow-up
          5
          ·
          1 year ago

          Yeah, although having now seen two commenters with relatively high confidence claiming that counting codepoints ought be enough…

          …and me almost having been the third such commenter, had I not decided to read the article first…

          …I’m starting to feel more and more like the stdlib should force you through all kinds of hoops to get anything resembling a size of a string, so that you gladly search for a library.

          Like, I’ve worked with decoding strings quite a bit in the past, I felt like I had an above average understanding of Unicode as a result. And I was still only vaguely aware of graphemes.