14 comments

[ 3.8 ms ] story [ 42.1 ms ] thread
to add to that list

https://stackoverflow.com/questions/24508592/how-to-iterate-...

https://stackoverflow.com/questions/33463511/how-to-reverse-...

they removed the c-like for-loop in swift, which IMO is a wrong decision.

c for-loop is an example of "less is more", a single syntax to cover all cases.

their argument is that c for-loop is not "swifty" and not beginner friendly (I don't understand why the above is). But if one can't learn c for-loop within 5 minutes, perhaps the person is unsuitable for any programming activities.

I've used Swift since version 1 and stopped using it at 4-ish. Not surprised to see they're still finding ways to mess with people, and glad you could add to the list.

For the project I used to work on, we were dealing with strings a lot and decided one day to make our own strings (implemented basically as arrays of characters*) because even the patient guy on our team had lost patience with Apple's strings. Apple changed how strings work several times after that, and we were unaffected. I guess if the project were still around, the loops would've gotten it one day.

* 1 character to us = 1 extended grapheme cluster aka what a human would see as one character

How did you handle characters of different lengths? Was each extended grapheme cluster its own array?
Each element in the array was a Swift Character if I remember correctly, or maybe a String.
To clarify, a grapheme cluster can be a single Character in Swift. That's one nice thing.
I don’t use Swift very often, one App Store product and many evenings of hacking. I find the language to be really nice in general. Swift 5 and SwiftUI all seem well engineered and documented.
You understand why it’s like that right?
If you're referring to the link in the title about substrings, I understand the reasoning behind the current version, but it's still bad. It's even worse that it's changed at least 5 times.
Is String and Substring in swift all that different from String and &str in rust? It's definitely an odd thing to have such an explicit memory management construct in a language that largely tries to make you not have to think about memory management (unlike rust) but it's not like it's unprecedented in a modern language either.
Not conceptually very different, but Swift's syntax for that is just overly complex, and yeah there's the mismatch as you've pointed out. &str in Rust never confused me.
(2016), actual title: "How does String substring work in Swift"