The main reason, I think, that Swift strings have `count` is that they conform to the `Collection` protocol. Swift's stdlib has a pervasive "generic programming" philosophy, enabled by various protocol heirarchies.
So, given that the property is required to be present, some semantic or the other had to be chosen. I am sure there were debates when they were writing `String` about which one was proper.
In Swift 3 (and probably previous versions as well), `String.count` defaulted to the count of the Unicode scalar representation. In this version, iterating over a string would operate on each Unicode scalar, which often doesn't make sense due to the expected behaviour of extended grapheme clusters. So, this is my best guess why `String` in Swift 4 and later ended up with the current default behaviour.
This conforms exactly to our intuition about what a "collection" is. Some (exact) number of items which share some meaningful property in common such that we can consider them "the same" for purposes of enumeration and iteration.
In the real world, we also have to decide what our collection is a collection of! Let's say we a pallet of candy bars, each of which is in a display box. If we want to ask "how many X" are on the pallet, we have to decide whether we're asking about the candy bars or the boxes. Clearly we should be able to answer questions about both; just as clearly, operations on the pallet should work with boxes. Because we don't want to open them, and even if we do want to open them, we have to open them, we can't just ignore their existence!
I assert that the extended grapheme cluster is the "box" around bytes in a string. Even if you do care about the contents (very often you do not!) you have to know where the boundaries are to do it! Because a Fitzpatric skin tone modifier all on its own has different semantics from one found within an emoji modifier sequence.
So it makes perfect sense for Swift to provide one blessed way to iterate over strings, and provide other options for when you're interested in some other level of aggregation. Which is what Swift does.
Strings were done well, because they are just BudirectionalCollection and not RandomAccessCollection on graphemes, which is usually what you would want (especially as an app developer writing user-facing code). The other views are collections in their own right. By conforming to Collection a string can do things like be sliced and prefixed and searched over “for free”, which are extremely common operations to define generically.
OOP using a meta-object protocol is very based indeed.
Unfortunately, only Common Lisp and Lua do it that way.
Actor models are pretty based as well, and have a better historical claim to the title "object oriented programming" than class ontologies do, but that ship has sailed.
Yes agreed; I'm guessing by meta object that is the module pattern from fp with syntax sugar? I use the module pattern with typescript interfaces plus namespaces and it's pretty great.
100% on the actor model. My visual programming platform is basically based on actors, but the core data model is cybernetic (persistence is done via self referentiality). Alan Kay got shafted by the creation of C++, OO in the original conception was very based.
So, given that the property is required to be present, some semantic or the other had to be chosen. I am sure there were debates when they were writing `String` about which one was proper.