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
