Re:Swift 6
by paperplatter on Tuesday September 17, 2024 @11:34PM
(#41575510)
Swift was designed around emojis it seems. First page in the manual shows how you can use emojis as variable names. I get why Apple wants to be clear how there are different ways to index into strings (even if this is motivated 99% by emojis), but still, the API didn't have to be this confusing or have so many breaking changes after GA.
The weird thing about arrays is they're different from all other objects, including NSArray which is by reference. No other language does it this way. C++ has pass-by-value vectors, but that's because everything else is too.
Or you know, the couple of languages people speak that are not using ASCII…
Re:Swift 6
by paperplatter on Wednesday September 18, 2024 @12:53PM
(#41582348)
The issue here isn't ASCII vs unicode, it's specifically symbols that are composed of multiple unicode codepoints.
Re:Swift 6
by paperplatter on Wednesday September 18, 2024 @06:00PM
(#41586040)
(Which btw isn't exclusive to emojis, there's also Hangul Jamo that the Unicode standard says is used for "archaic" Korean characters, but emojis are probably the main use case.)
You can get a `utf8` or `utf16` "view" of a string, and index it like normal array (`myString.utf8[0]` gets the first utf8 character). But it's not going to work with complicated emoji, or different languages that may have representations into utf16, etc. Again, I think the vast majority of people don't care for complete correctness across all possible string representations, and possibly Swift has gone too far here — as noted by all the Stack Overflow posts and clunky API
On the array-pass-by-reference, I'd argue that it's valuable to learn those semantics and they aren't particularly complicated. They offer huge benefits relating to bugs caused by unintentionally shared state. Marking the parameter `inout` is a small price to pay, and really forces you to be explicit about your intentions