[swift-evolution] Revisiting 0004 etc. - Swift deprecations

[Andrew Bennett]

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 at 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/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 at 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 at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160403/a0b0a768/attachment.html>