[ASalazarMX]

Objective C is good once its philosophy "clicks" with you, but any new development I would start in on Swift. Swift is a much nicer language, feels like compiled Python.

Same with Android, I would choose Kotlin before Java if it was my choice.

People still working with Objective C might be like I recently was: maintaining a sizable codebase which, unless Apple breaks something, porting to Swift is not justifiable to management.

[gigatexal]

You don’t think the swiftisms they added like trying to get rid of conventional looping constructs is odd?

[favorited]

There's nothing unconventional about for/in loops on Apple's platforms. Even in Objective-C, NSFastEnumeration has been the recommended default loop mechanism for a decade+ now.

[matthewmacleod]

Absolutely not. These are among the best features; in any language that has modern control flow, I rarely if ever use old-fashioned loops.

[ken]

What are "old-fashioned loops"? Does that mean C-style?

As an also Lisp programmer, I find Swift's limited (and fixed!) set of control flow constructs downright ancient. They added for-each loops, but that's it. We had more "modern control flow" in the 1980's.

[kccqzy]

Diversity in control flow constructs isn't necessarily a good thing. In imperative languages you see goto being discouraged and removed. In functional languages you see things like call-with-current-continuation discouraged.

[ken]

It is to me. The alternative is implementing them ad-hoc in every function. (Or perhaps waiting another few decades for Swift to add them to its compiler.) Having used many languages at different points on the power spectrum, I remain unconvinced that there's any advantage to omitting abstraction capabilities and forcing programmers to deal with it.

Besides, both of those examples are essentially non-local jumps, and I'm not sure I'd describe them as "modern".

In a sense, Swift already allows diversity in control flow constructs, via closures and the trailing closure syntax. It's just somewhat awkward, and not flexible enough to implement, say, most of Lisp's ITERATE library. That's packed full of exactly the kinds of control flow constructs that I have to write out by hand in Swift every day.

[mnem]

Do you mean the c style for loops? The were removed in favour of iterator style loops (for foo in bar { ... }). Or are there some others I haven't noticed?

[ShamelessC]

It's actually more curious that they didn't have iterator style loops from the beginning. It's a pretty standard feature in newer languages and even plenty of older languages are adding support for it.

[NobodyNada]

Swift had iterator-style loops from the beginning. It also initially supported C-style "for (i = 0; i < j; i++)" loops, but they were removed very early on (because in practice, they're rarely used for anything except iteration, and iterator-style loops are much more readable and less error-prone).

[jmnicolas]

I never looked at Swift, but for example how do you wright 10 times "hello world" on the command line if you don't have for loops ?

You could do it with a while loop (if it exists in Swift) but I'm at a loss as to why you would remove a for loop from a programming language.

[NobodyNada]

Iterator-style loops are much clearer and more concise in almost all cases. In this case you can iterate over a range:

    for i in 0..<10 {
        print(i)
    }

[oflannabhra]

I don't. I much prefer a chain-able functional approach to multiple mutating loops.

[AJRF]

You can always pass in an iterator tracker via the following, much cleaner!;

  for (value, index) in arr.enumerated() { // Loop body }

[ASalazarMX]

To be fair, no language is going to be perfect. I don't mind them, but I remember how odd enumerations and mappings felt at first in Python. IMO, overall, the pros of Swift vastly outnumber the cons, when the alternative is Objective C.

[gameswithgo]

Thats kind of the thing to do in C# as well, and Java Streams, and in Rust the fastest way to do loops is not to do them but use iterators.