These emoticons should never have been a part of Unicode in the first place. Second big mistake of that org after the Unihan fiasco.
It’s not wrong that "🤦🏼♂️".length == 7 (2019)
71–80 of 315 posts
Re: It’s not wrong that "🤦🏼♂️".length == 7 (2019)
#72[deleted]
Re: It’s not wrong that "🤦🏼♂️".length == 7 (2019)
#73Earlier quoted context omitted.
That means 7 is also a measure of bytes, just slightly more awkward. So it's roughly on par with 17. For 5, the idea is that while you might want to iterate code points, the total number of code points is less useful than either grapheme count or byte count. I think that argument makes sense.
> That means 7 is also a measure of bytes, just slightly more awkward. It's not a real measure of bytes though. It's the count of bytes in an encoding scheme that is (probably) neither what you use to communicate with the outside world nor what your language runtime uses. (And certainly it's no better than 5, since that's also a measure of bytes in a particular encoding).
Lots of systems use UTF-16 internally and externally. Counting bytes in UTF-16 is, on average, almost as useful as counting bytes in UTF-8.
I don't think just about anything communicates in UTF-32. 5 is basically just a codepoint count, and as such I don't think its usefulness rating should be between the byte counts.
Re: It’s not wrong that "🤦🏼♂️".length == 7 (2019)
#74Is there a situation where I am going to try to get the length of an emoji and I care about the outcome?
Enforcing a character limit on user input.
Re: It’s not wrong that "🤦🏼♂️".length == 7 (2019)
#75Until reading this I had never heard of UTF-32. It doesn't seem like a good way to encode strings.
Re: It’s not wrong that "🤦🏼♂️".length == 7 (2019)
#76this one one of those things that people point to when comparing languages, but in reality rarely matters. with Go, you just get the number of bytes, which the the correct default thing to do: https://godocs.io/builtin#len if the language default was anything other than this, THAT WOULD BE WRONG and unexpected. I would prefer the default to be the dumb, fast thing. then if I want the slow, fancy thing, I can import s…
This is only if you want strings to be sequences of bytes. If you want strings to be sequences of code points, it is more sensible to define string length as the length of the sequence. I prefer the latter (for coded text) because it is closer to the meaning of the string. Sequence of code points is always sequence of code points, but a sequence of bytes may not correctly encode a sequence of code points, and bytes in encoding are not in one-to-one correspondence with code points in string. So I see no reason to care about individual bytes per se in the string's code.
Re: It’s not wrong that "🤦🏼♂️".length == 7 (2019)
#77All these abominations are because of non strict typing
String = List ( Char )
Chars don’t have a length, like a number doesn’t have a length - unless you talk about number of bits. If you are working with strings stick with strings. The string of a single character should be “1”. Just enforce proper typing. Anything else is not consistent.
Re: It’s not wrong that "🤦🏼♂️".length == 7 (2019)
#78Re: It’s not wrong that "🤦🏼♂️".length == 7 (2019)
#79These emoticons should never have been a part of Unicode in the first place. Second big mistake of that org after the Unihan fiasco.
Emoji's are a fun way to illustrate a problem that happens with languages too.
Re: It’s not wrong that "🤦🏼♂️".length == 7 (2019)
#80Unsurprising that (at least some implementation of) Swift does the least wrong thing in returning 1. I think it's also one of the few languages that will return a count of 1 for the madness that is country flag emojis https://docs.swift.org/swift-book/documentation/the-swift-pr...