While this style works, and definitely can substitute for a classical for loop, it is not quite as nice, because it cannot limit i’s scope to the loop. The variable will be visible outside of the loop body.
Charles > On Apr 2, 2016, at 8:43 PM, Andrew Bennett via swift-evolution > <swift-evolution@swift.org> wrote: > > On that note here is a convenient pattern I've used in the rare cases I > haven't been able to convert to a "for in" syntax when refactoring: > > var i = 0 > while i < 10 { > defer { i += 1 } > print(i) > } > > To be honest I don't really mind this syntax, I often found during > refactoring: > * the c-style "for" was broken up over multiple lines anyway > * I wanted the last value of `i` outside the loop, so it was written "for ; > check; incr" > * It still works with continue, although it does increment "i" on break > > > On Sun, Apr 3, 2016 at 11:19 AM, Ross O'Brien via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > Because you're coming to the discussion late, the arguments you're making are > a little out of date. It's no longer a case of not removing these features. > It's now a case of having a compelling reason to put them back. > > I trust you've read the proposals that were put forward. For the benefit of > those reading, they're here: > https://github.com/apple/swift-evolution/blob/master/proposals/0004-remove-pre-post-inc-decrement.md > > <https://github.com/apple/swift-evolution/blob/master/proposals/0004-remove-pre-post-inc-decrement.md> > https://github.com/apple/swift-evolution/blob/master/proposals/0007-remove-c-style-for-loops.md > > <https://github.com/apple/swift-evolution/blob/master/proposals/0007-remove-c-style-for-loops.md> > > There are several disadvantages listed for keeping these two features. Those > are the arguments you need to counter. As it happens, both proposals refer to > the metric of 'if this wasn't already in Swift, would it be accepted for > Swift 3?' and both features have been deemed to fail this criterion. That's > what you need to address. > > Bear in mind these decisions were made several months ago, and both features > have already been deprecated as of Swift 2.2, which is now in use in > production code, many developers (including myself) are already refactoring > their code to remove uses of these syntax forms. > > > On Sun, Apr 3, 2016 at 12:45 AM, John Heerema via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > Warning - long post. > I know that some folks really hate long posts, so let me apologize right > now for this being a long post. Please feel free to skip right on past it. > I posted it on a weekend, when there¹s less mailing list traffic, but that > doesn¹t make it any shorter. > > Warning - revisits two approved deprecations. > If you really, really hate it when people want to revisit decisions that > have already been made, please just skip right past this post. My > apologies for not contributing to the discussion when these decisions were > originally being made! > > The day that Swift was announced at the WWDC was very > exciting for me, and I immediately read the Swift book from beginning to > end. > Swift quickly became my favourite language: I felt that the Swift language > developers had created a beautiful language that combined expressiveness > with > practicality in a way that made Swift code both powerful and easy to > understand. Swift was crafted by some very smart and practical people. > > To put my thoughts into perspective, I should mention that > I¹ve taught Computer Science at a senior University level for years, and > have > worked in industry for decades. As a computer scientist, I¹ve had a strong > interest in computer languages for many years. I became an Apple developer > upon > purchasing an Apple Lisa a very long time ago. > > Over the past couple of years though, I¹ve seen what I think > of as a growing emphasis on strict feature orthagonality at the expense of > practicality in Swift. Perhaps this because much of the feedback on the > language has been provided by those of us who are interested in computer > languages. But for whatever reasons, the Swift language seems to have > become > more cluttered and less friendly. > > As I¹ve gone through the various beta releases, I¹ve seen > changes that detract from the experience of using Swift, for reasons that > seem > related to ³language purity². > > I was finally moved to try to express my thoughts after > seeing a couple of what I think of as particularly inadvisable proposals > for > Swift version 3 and beyond. > > Unary increment and decrement operators: ++ and ‹ > > The first of these was the now approved removal of Swift¹s > convenient unary increment and decrement operators. I would agree with > some of > the comments that have been made about these operators not being quite > orthogonal with other expressive elements in the language. Nonetheless, > they > are a handy and popular way to iterate over enumerable collections, and to > increment and decrement a variable that is used for purposes other than > iteration. They also lend themselves to being extended to other data > types, such > as position pointers in linked lists, where they can implement the > convenient > concept of ³the next thing² (which += does not provide). > > The desire to get rid of these rather harmless operators > reminds me of some of Apple¹s own history, and the history of computer > languages in general. Niklaus Wirth didn¹t care for shortcut operators > either, > and so Pascal never got them. > > However, Apple eventually moved away from Pascal to C, even > though C is in many ways a deeply flawed language that is responsible for a > wide litany of software errors. Why? I personally really liked Pascal, but > many > (most) developers didn¹t care for the language. I¹d argue that developers > preferred the flexibility of C to what they saw as the overly restricting > constraints of Pascal. > > One of the surprising reasons that I heard a lot at the > time, was that developers didn¹t want to lose C¹s shortcut operators. If > Wirth > had been willing to give Pascal some of C¹s convenience operators, things > might > well have turned out differently. Developers hate typing. > > The notion that there should be exactly one way to do a > particular thing sounds like dogma to me: not practicality. If people are > concerned that unary operators confuse beginners, I would encourage them to > convince educators not to teach them to beginners. Anyway, there are a lot > of > things in Swift that can confuse beginners! > > Although it¹s hard for me to believe that having these > operators return void has been seriously considered, I would argue that > this > would be even sillier than removing them. A lot of developers use both C > (or > Objective C, C++, C#, Java, etc. etc.) and Swift having those unary > operators > act completely differently in Swift would be a great way to alienate those > developers. > > Let¹s not forget that Swift > is not the lingua franca of the computing world. It¹s an upstart that > needs to > attract the development community. Why repel people coming from the various > C-like languages without a really, really, convincingly good reason? it¹s > better for an upstart to attract than to repel. > > Right now, there are an awful lot of developers who are used > to, and like the convenience of unary increment and decrement operators. > Removing them seems bound to annoy developers and diminish the popularity > of > Swift, in exchange for Š well, not very much except for a tiny bit of > language > purity. That just seems silly to me. > > C-style For loops > > Removal of C-style For loops has already been approved for a > future version of Swift. Even though I find the C-style For loop to be a > bit > ugly and unintuitive, I believe that removing it was the wrong thing to do. > > It comes down to flexibility and expressiveness. The reality > is that C-style For loops easily implement certain operations that are more > difficult to implement without them. > > I¹ve seen comments that C-style For loops are ³hardly ever > used², and that ³hardly any² algorithms really need them. I believe that > ³hardly any² is a lazy mental shortcut for ³Well, I don¹t like them, and I > I > don¹t use them, so I don¹t think that any anyone who¹s important uses > them.². > > Yes, there are many cases in which I believe that Swift > provides looping structures that are safer and easier to understand than > the > C-style For loop. I¹d even say most cases. But I work in the scientific and > engineering domains, and can point to many instances of looping structures > that > are easily expressed with a C-style For loop, but are clumsy to implement > without it. > > In the world of the natural sciences, there are any number > of instances of loop increments that requires some kind of a calculation. > There > are any number of instances of dynamically calculated loop termination. > > Swift¹s stride has some nice features for simple increments, > but also has some important limitations. Among them, it involves the two > step > process of first creating an enumerable set, and then iterating over it. > In the > natural sciences, it is not uncommon for complex loop increments to be > used in > loops that are executed millions of times. > > Conceptually, creating an enumerable set, and then iterating over it, > reeks of the arrogance of assuming that computing resources are unlimited. > Even > though the compiler may optimize the stride into the loop structure, it > feels > like unnecessarily creating a gigantic enumerable set. > > Whether we like it or not, the enduring popularity of the > C-style For loop comes from it¹s flexibility. Swift doesn¹t have a better > alternative that also provides the same flexibility. So don¹t take it > away. If > you don¹t like it (I don¹t always either), think of something that is > clearly > superior in 100% of use cases. Even then, I would argue against removing > it. > > I would argue that the C-style For loop implements some > rather Swift-like concepts. The syntax provide for three closures: one > each for > (a) things to do first, (b) things to do when deciding whether to stop > iterating, and (c) things to do after each iteration. How is that contrary > to the principals of Swift? > > Just like pretty much everywhere that Swift allows closures, > they can be used to write code that is difficult to understand. But the > syntax > is general and flexible enough to have survived intact for half a century. > > It¹s the carrot vs. the stick. Developers prefer the carrot. > The belief that we can force developers to write better code by taking away > language features, has not historically met with success. Let me say that > again, because I think it¹s important. Developers who are given a choice > between C and a ³better² language (say Modula-2, or Swift) are unlikely to > react favourably to being told ³we¹re taking away this feature of C that > you > like, for your own good, because you¹re too stupid to use it sensibly². > Taking away well-understood expressive language elements, and replacing > them with something less expressive, is not going to win developers over. > > C-style For loops haven¹t changed in half acentury, because they work. > A lot of other languages have also adopted them, because they work. > > If I may, I¹d like to take the English language by way of > analogy. English contains a lot of weird, irregular language elements. > There¹s > no single way to express a concept. Instead, there are many, subtly > different > ways to express yourself. > > But, for all of its weirdness, English has remained popular > for centuries, whereas more ³sensible², ³regular² languages like Esperanto > never caught on. The reasons are flexibility and expressiveness. The same > thing > applies to computer languages. > > If we only look inside the world of compilers and computer > science instruction, to see if we need the flexibility of C-style For > loops, we > might mistakenly think that we don¹t. But those domains are relatively > simple > in comparison to the physical sciences. Our experience there doesn¹t always > translate to the more complex world of physical reality. So let¹s not throw > away convenient and useful language features just because we don¹t > personally > care for them. > > Don¹t make Swift Yet Another Interesting Experiment in > language design that wasn¹t widely adopted, and > ended up being relegated to the dustbin of history. > It would make me sad to see the best new computer language > in ages become just another niche language. We already > have enough of those. > > So, all of you folks who voted to remove these things, please don¹t hate > me! > > Regards, > J. Heerema, Ph.D. > > > > > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org <mailto:swift-evolution@swift.org> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution> > > > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org <mailto:swift-evolution@swift.org> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution> > > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution