> wants wrong with being “the C# of Apple”?

Oh nothing. It makes sense for Apple to want a more modern language to replace the now aging Objective C. In turn, that meant Swift was not on my list of languages to try, but instead on my, possibly a language I'll be forced to use one day list, just as Java, C#, JS, and all are, by simply being defacto languages for some platform which depending what you work on, you have no choice over.

But then I started seeing people in the comments claiming things like: "Swift is one of the most interesting languages right now". So I was like... Hum okay, what did I overlook?

Now, I'd be okay with people saying that it improves drastically on C# and Java. If people think Swift is a dramatic improvement because of the sum of its part, like just little details here and there that end up making it much better, and they think that in turn could lead Swift to replace both Java and C# if it gained support on other platforms. That could make it quite interesting as well. So I'd be up to listen to those arguments as well.

Swift takes a lot of good choices from other languages and puts them together in a cohesive package. It's not necessarily something on the bleeding edge of a new frontier, going someplace that nothing else has gone, but it is a pleasant way to use fairly recent programming language theory in your day-to-day code.

> the Character type is closer to what ‘normal’ people think a character is

I'm sure I'm missing some nuanced downside to this, but this sounds fantastic. I've never fully understood the difference between Unicode code points and code units[0], and would love to think less about this sort of thing in Java (for ex. when using String#toCharArray).

[0] I'm just regurgitating language from the String javadoc, this sentence might not even make sense.

Downsides: indexing into a string isn’t O(1). To find, say, the 200th character in a string, you have to go through the string data from the start.

So (not Swift, nor, AFAIK, any other existing language)

  for i = 0 to stringlen(s)
    print s(i)

would be O(n²), so slow for long strings. It’s rare to have code that accesses the n-th character of a string without accessing all earlier ones, though, and idiomatic code

  for c in s
    print c

can be efficient (not as efficient as iterating over fixed size units, but not dramatic, either)

Also, requiring String to know of what code points in Unicode are “combining” means carrying a few tables around in the implementation. That could be problematic when porting Swift to devices with small amounts of memory. It also, I think, ties Swift to a version of Unicode. You cannot predict what code points in future versions will be combining characters (https://en.wikipedia.org/wiki/Combining_character)

I also think there are a few corners where Swift doesn’t reach the goal of “a character is what naive users expect”. Ligatures in Unicode might be problematic. For example. “fl” is a single Unicode code point, but, ideally, would be two characters “f” and “l”.

I could see issue if using it for splitting strings, but I guess it also depends what Swift assumes to be what normal people think a character is.

Most normal people assume Unicode grapheme to be characters. That would be the set of symbols you'd consider a single letter if you were to visually count the number of symbols in the string.

In Unicode though, some code points are non visible, yet are part of the string. So for example, the character at i+1 for some match against a letter might not be the next visible letter. I can see this causing issue either way.

Honestly, I'd say it's best to just learn this, it you'll have some weird bugs one way or another.

Basically, you have code units, those are the smallest chunk of bit that has meaning in Unicode and thus can be sent over a wire, streamed or decoded. In UTF-16 encoding, which is what JVM uses, code units are 16 bit.

The history helps. In the beginning, each character in Unicode was 16bit. So you could represent all Unicode characters with 16bit only. Later, there were even more characters added, and it couldn't fit into 16bit. So UTF-16 where the 16 tells you the code units is 16 bit no longer could represent all characters in one 16 bit unit. Thus code points were invented, those are characters that span two code units 16bit + 16bit. Together they represent the new characters that didn't fit in the single 16bit range.

So nowadays, it actually takes 21 bits to represent all Unicode characters. There's three encodings: UTF-8, UTF-16 and UTF-32. Their number correspond to the bit size of their code units. In UTF-8 we break each character into 8 bit units. In UTF-16 we do so in 16 bit units, and in UTF-32 into 32 bit units.

Ok, now back to measuring length. We can say tell me the number of code units used to represent the string. That's what Java's string.length() does. Or we can say telle the number of bytes needed to represent the string (a byte is 8bit). That's what converting to byteArray and getting the length of the array does. Or you can say tell me the number of code points (Unicode characters) the string contains. In UTF-16 a code point can be 16bit (composed of one unit only), or it can be 32 bit (composed of two units). But not all Unicode characters are visible, so the user might be surprised to get a length that is greater than what it counts visually. So you can also get the number of grapheme in the string, which are "visual characters". In Java you can use BreakIterator to count those. That said, Unicode grapheme don't always make sense to what each speaker of each language would consider a character. That's for example some languages might consider a combo of two letters one character with one pronunciation, etc.

Finally, I'll say there's another interesting length. It's the font width in terms of physical measures like pixel count.

So basically, each measure might be most appropriate depending what your measuring for.

I think the real issue is that we didn't adopt new terminology of Unicode yet. You should try to start referring to things as code units, code points, grapheme and font width/height. And stop using the word character or letter.

And then just make yourself a little library that has string.codeUnitCount(), string.codePointCount(), string.graphemeCount() and string.pixelWidth().

And when you don't care about the difference between these, I'd argue that code unit count is the best default for length, which is why I don't actually disagree with string.length counting code units. Cause I think of string.length from the perspective of looping over the smallest units of the string.

To make sure I have this right:

Graphemes are comprised of code points, code points are comprised of code units, and code units are a chunk of binary of variable length depending on the UTF flavor.

UTF-8 uses smaller code units so that strings containing only ASCII (for ex.) are of optimal size (in terms of memory). UTF-32 would mean each "character" takes up 32 bits regardless.

I think the String javadoc could be clearer here. The class overview mentions these concepts but the methods are not as forthcoming.

Thanks!

You got it. I find this SO does a good concise explanation for them: https://stackoverflow.com/a/27331885/172272

I am unsure how your arrays link is relevant?

You’re right. I had forgotten that the bridging between Swift Arrays and NSArray isn’t purely 1:1 (https://developer.apple.com/documentation/swift/array#284673...). (IIRC, it used to be)

Arrays still are not guaranteed to be contiguous in memory, though. If you want that, there’s ContiguousArray (https://developer.apple.com/documentation/swift/contiguousar...)

> - Collections are value types (implemented somewhat efficiently by having copy-on-write collections)

Isn't copy on write data structures mostly discouraged idea these days?

Swift already uses reference counting for memory management, so copy-on-write is basically free -- it just checks to see if the collection's reference count is greater than 1 before writing.

It's decidedly not free. Reference counting in Swift can be (is?) a major bottleneck. See this project: https://github.com/ixy-languages/ixy-languages and its discussion on Swift performance: https://github.com/ixy-languages/ixy.swift/blob/master/perfo...

It’s free since the language is already using reference counting. But yes, retain/release traffic is often a huge problem in performance-critical code.