It always struck me as a fairly warty syntax.
Consider Python where you usually do:
for item in iterator
If you want an integer sequence it's: for integer in range(1, 100)
and for those rare occurrences where you need an integer index as well: for index, item in enumerate(iterator)
Swift seems to have a similar approach. Why would you ever want the C-style iterators?`for (l, r) in zip(c1, c2) {`
It is not simply motivated by making code concise, I would say `for num in collection.reverse()` is less error prone and clearer than `for (var i = collection.count; i >= 0; i--) { var num = collection[i] ... }`
The reverse collection iterator is computed lazily too, so there is no little perf overhead
Chalk this one up to shit hacker news says.
Things that require a double take to read and parse do not help. Additional solutions to the same problem do not help.
There's a lot of cleverness that can come up in programming that may make for neat/short writing but that makes reading and purpose less clear. i++/++i helps with that with no special benefits.
I like how the Swift team approached the decision to remove them: thinking on whether it would make sense to add them had they not been there. And it doesn't, as they solve no particular problem; they're just a special, (not much) shorter solution to something that's already solved.
Maybe you can bring it back when we get hygienic macros (Swift 4.0? fingers crossed)
IMHO, these operators are the worst features of C. Particularly I never understand the necessity of both i++ and ++i operators in language at the same time.
I don't mind removing them but their usecase is obvious: make the code more concise and more readable (and yes, if you program in C on daily basis you don't require a double take or thinking about what ++ does).