How the hell you inserted an emoji in title? Afaik we cant use emoji on this website
It’s not wrong that "🤦🏼♂️".length == 7 (2019)
91–100 of 315 posts
Re: It’s not wrong that "🤦🏼♂️".length == 7 (2019)
#92Am I wrong for assuming the .length should return a length in bytes? If you want to use 32bit units, then multiply your output by 4. If you want to do Unicode string manipulation and length counting, then use specific functions for that - but the base internal .length function should just output bytes.
>then multiply your output by 4.
That is not how UTF-32 works.
>but the base internal .length function should just output bytes.
Do you think the length of an `int64_t[3]` array should be 3 or 24?
Re: It’s not wrong that "🤦🏼♂️".length == 7 (2019)
#93Unsurprising 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...
“Least wrong” sounds very silly. Its like programmers are discovering theres a difference between bytes, unicode code points and grapheme clusters and are unsure about how their favorite programming language represents strings, and then decide there should be some behavior that doesnt follow from the documentation.
The “length of an emoji” depends on the data type used to represent it. Its that simple and that correct.
Re: It’s not wrong that "🤦🏼♂️".length == 7 (2019)
#94Earlier quoted context omitted.
What do you mean there is no such thing as a character when grapheme cluster is exactly that? This is also the out-of-context , and people get confused because instead of this human context attribute they've been forced to use all the other alternatives that require more knowledge
Characters in context are printable or non-printable/formatting marks right? I agree they probably meant grapheme clusters, but grapheme clusters can vary dramatically in width so the point of the conversation was to explain why a bounding box was a better approximation of their goals.
> grapheme clusters can vary dramatically
so do 'www' and 'iii' (though less dramatically), that't not a foreign concept to designers, not sure they'd want to bound 'www' to the width of 'iii'
Re: It’s not wrong that "🤦🏼♂️".length == 7 (2019)
#95Earlier quoted context omitted.
In Python len() on a bytes type gives you the number of bytes, and len() on a str type gives you the number of codepoints. I think that makes sense, as strings are only intended to deal with text, and you should never have to worry about byte indexing at all.
The argument is that indexing by codepoint is even less useful than indexing by byte.
As someone who has done both, I'd say that argument is wrong. It is much more convenient to index by code point. Indexing by bytes is almost always what you don't want to do, and leads to a lot of errors.
Re: It’s not wrong that "🤦🏼♂️".length == 7 (2019)
#96All 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.
Python has strong typing which seems to be what you mean here rather than strict typing.
A "character" is not a well defined term in Unicode, rather the "base" that does not vary across implementations is code points, which is what Python measures when you get the length of a string.
Re: It’s not wrong that "🤦🏼♂️".length == 7 (2019)
#97Earlier quoted context omitted.
Why would you want dumb??? (and it's not expected that a character's length is>1 unless you've been conditioned to excpect it)
Because whenever you want to store or transmit a string only the byte count matters (the size of the string). All the fancy unicode stuff on top of bytes is for the display layers to handle. The default should be grounded to the reality of the programmer.
Human interaction is a more grounded reality for programmers vs. the dumb land of pure bytes, so even at that conceptual level the default should be smart
And bytes is the only thing that matter for a specific type of string, conveniently named, sequence of bytes
Re: It’s not wrong that "🤦🏼♂️".length == 7 (2019)
#98It's 1 in elixir which measures graphemes by default. iex(3)> String.length(" ") 1 Edit: looks like HN doesn't support that emoji in code blocks, at least.
it's also 5 if you like:
> length(' ')
Which is: [129318, 127996, 8205, 9794, 65039]
Re: It’s not wrong that "🤦🏼♂️".length == 7 (2019)
#99How the hell you inserted an emoji in title? Afaik we cant use emoji on this website
[deleted]
Re: It’s not wrong that "🤦🏼♂️".length == 7 (2019)
#100Earlier quoted context omitted.
> 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.
Only Windows and Java come to mind - and BOTH of those are insane for sticking to it when the entire rest of the world has moved on.