The loop variable is just that, a variable, and therefore will not work as expected when captured in closures that are executed later, e.g. The C-style for-loop is syntactic baggage (the semicolons do not separate its parts very well) and suffers from the problem that it is imperative, i.e. Initially I was hesitant but now I support this change.
#Swiftify review code#
I read the proposal carefully, looked over the responses in the mailing list, and spent several hours reading through my collection of Swift and Python code to look for any cases where lack of a C-style for-loop was a serious impediment. I don’t recall any suggestions to add these constructs to Python I believe the same would hold true if these constructs weren’t already in Swift.ĥ. Python and Swift have similar aims for readability and safety. I feel the same will hold true for Swift. I’ve never had a problem doing complex iterations or loops – indeed, I find Python to be a very powerful language for iteration. Python has neither ++/- operators nor C-style for-loops. My primary programming language is Python (for now). In my experience, using explicit iterables results in much simpler code in most cases.Ĥ. It would be harder to make this sort of mistake with for-in loops or similar replacement constructs. Print("The \(i)th element in bar is \(bar).")
For-loops are often used to iterate over arrays, but it’s easy to make off-by-one errors that mean you miss elements or try to read off the end of an array. The alternatives tend to more expressive and explicit, and feel more Swift-like. This proposal fits nicely with Swift, for a few reasons:
I can’t imagine a scenario in which I’d recommend using the C-style for-loop instead of a more expressive Swift construct (and was unable to find a counterexample in my Swift or Python code).ģ. The for-loops feel like a piece of legacy baggage I can’t imagine them being added (at least in this form) if they weren’t already in Swift. Just as it’s important to add new features, it’s also important to consider what should be removed.
0 kommentar(er)
