Hi Ted, I don't think many of us that are active on this mailing list had the opportunity to provide feedback on this proposal review. I very much agree with you on many points that you bring up below. I have spent a lot of time scratching my head wondering why it was so important to remove certain syntax from Swift, such as C-style loops, unary increment, and unary decrement. Leaving them there increases compatibility of C code with Swift, and leaving them there keeps them opt-in. If you don't want to use it, you don't have to. However, the changes definitely force developers to use newer syntax, which runs contrary to the "opt-in philosophy" that the core team has impressed on the community.
I'm going to play devil's advocate though. Will the tools for Swift 3 automatically make the necessary changes to source to comply with the new syntax? If so, is it so bad? I've been using the C language and all of its variants for more than 32 years. Hence, it is easier on my eyes and brain if there is some compatibility there. Personally, I think leaving this syntax in the language eases migration. Although, I've been learning so many new languages over the last decade that it seems to matter less with time. However, I can't seem for the millions of developers that write code for OS X and iOS. Cheers, -Patrick > On Mar 18, 2016, at 4:28 PM, Ted F.A. van Gaalen via swift-evolution > <[email protected]> wrote: > > As most colleagues (that's what I think you all are, spanning two generations > :o) > might have noticed, I am not exactly happy with the removal of the classical > for-loop ( for ;; ) but the damage has been done, so I will soon > present a proposal for a better alternative. Working on it. > I find this matter very important. > > I do not agree with the for-loop removal proposal authored by Erica Sadun, > > Important: > I would like to emphasize again that what I write is not intended personally. > > Also I realize that I am a bit late on this subject, but that is because I > was not here back then. > > I wil go through it point by point and try to explain why IMHO I think this > is not a good proposal. > --------------------- > > Evaluating proposal SE-0007 > Remove C-style for-loops with conditions and incrementers > • Proposal: • Author(s): Erica Sadun > > > > "The C-style for-loop appears to be a mechanical carry-over from C rather > than a genuinely Swift-specific construct." > > Could you explain to me why what, in your view, is > - a "genuinely Swift-specific construct” ? > - "not very Swift-like" ? > - "Swift-typical” ? > > "It is rarely used and not very Swift-like." > > This is definitely not true. > The classical for loop is one of the most frequently used language constructs > in most programming languages. > > > "More Swift-typical construction is already available with for-in statements > and stride." > > Except for collections, these are inconvenient, cumbersome and inefficient > "work arounds" as described later in my comments in this email. > > > "Removing for loops would simplify the language." > Removing screw drivers from a toolbox would indeed simplify the toolbox. > So would removing closures, classes, protocols etc. from Swift. > Simplification of a programming language can also have its disadvantages. > > " And starve the most common use-points for -- and ++, which are already due > to be eliminated from the language." > > "The value of this construct is limited and I believe its removal should be > seriously considered" > > There absolutely is no need to remove the for ; ; and also ++ -- from the > language. These can perfectly well co-exist with other language elements of > Swift. If you don't want to use them, that's fine, but for most people out > there who still want to use the for ;; and ++ -- . > > > "Swift design supported a shallow learning curve using familiar constants and > control structures. > The for-loop mimics C and limits the effort needed to master this control > flow." > > Yes indeed. It mimics C and also the for-loop or its equivalent in more that > 20 other programming languages. > > > "Disadvantages of For Loops > 1 Both for-in and stride provide equivalent behavior using > Swift-coherent approaches without being tied to legacy terminology” > > Most language elements in Swift ARE legacy, and that's ok, so one does not > have to re-invent the wheel again. > > "2 There is a distinct expressive disadvantage in using for-loops > compared to for-in in succinctness" > > What makes you think so? > > "3 for-loop implementations do not lend themselves to use with > collections and other core Swift types.” > > Agreed if it concerns collections. However, they can. Of course, it is much > easier and more readable to use e.g. 'for item in items" for collections. > > Please enlighten me: what "other core-Swift-types" do you refer to? > > "4 The for-loop encourages use of unary incrementors and > decrementors, which will be soon removed from the language." > Although the majority of programmers like the ++ and -- operators, I do > manage to understand why some do not like it. However ++ and -- are very well > suited for classical for-loops, in fact they even make them more readable... > Like so: > > 1. for i = 0; i < iterations; i++ { ...} > or > 2. for i = 0; i < iterations; i += 1 { ...} > > It looks like the first example is more readable. But yes, if it were that > the ++ -- would have remained in Swift, and also the classical for-loop, > using ++ and -- should probably restricted to be used in for-loops only. > > "5 The semi-colon delimited declaration offers a steep learning > curve from users arriving from non C-like languages." > > IMHO, this is utter nonsense. Even from those coming from other languages as > C++, C, if a mere three arguments separated by two semicolons are "a steep > learning curve" ? Then what to think about using closures, lambda's, classes, > inheritance, functional programming, protocols etc. ? > > "Impact on existing code > A search of the Apple Swift codebase suggests this feature is rarely used." > > A search of the Apple Swift codebase is not representative, because the scope > of this search encompasses only source code made by users of the programming > language Swift, which is partly still under further development. Faithfully > representative would it be to search in a wider perspective, which should > include source code written in variety of programming languages like > Objective-C, Java, C#, C++, C, PHP , Ruby, Go, Perl, Javascript, Dart, V. > Basic, Pascal, PL/1, Cobol, Rexx. Most of this languages have implemented > the for-loop (or equivalent) . Undoubtedly if one would do a search for > for-loop in these languages it would become clear that the for-loop is > heavily used. > > As a result of removing the classical for loop it is to be expected that lot > of people might consider thinking twice about switching to Swift, If they > have to live without (or cumbersome work around) language elements that have > proven to be very useful for at least a few decades... > > How do you arrive at such a conclusion? In this perspective, Erica, I am very > much interested to know if you have practical experience with using other > programming languages than Objective C and Swift. Have you built solid > applications with other systems, IDEs and languages? Also, did you consult > programmers working with other well established languages? > > "Community members of the Swift-Evolution mail list confirm that it does not > feature in many pro-level apps and can be worked around for those few times > when for-loops do pop up." > > If one browses through the App Store, one might notice that most apps work > with collections (e.g. customers, addresses, shopping items, videos, songs. > etc.) For these kind of applications, the for-in-collection statement in > Swift is great and well catering for these requirements. The result of this > is, that the majority of Swift developers will not be aware and not miss the > classical for-loop (or a new Swift equivalent for it at all) simply because > they do not need it. > > However, for those that make scientific, engineering, statistical, technical > and game apps, the lack of a simple but versatile iteration statement, which > in most cases can be compiled down to a simple and very fast assembler loop > is nothing less than a disaster. > > E.g. For the purpose of performance testing, in an Apple TV SceneKit app I am > currently building, I did replace replace the classical for-loop by a "for in > x.stride(..." for coordinate calculations. Performance dropped to about 45%, > this is unacceptable. The compiler cannot get rid of this. Working with a > collection based for-in will nearly always be twice as slow, for the simple > reason that the contents of the collection it has to process are by > definition unpredictable. > > In your proposal you offered the following example. I do not know where you > found this horrible piece of code. However, in this case it is not the > for-loop that is so bad, but the complete function. There are many better and > well structured classical for-loops to be found everywhere. I cannot deflect > my impression that you might have selected this particularly bad example > solely to amplify your proposal's case. > " > char *blk_xor(char *dst, const char *src, size_t len) > { > const char *sp = src; > for (char *dp = dst; sp - src < len; sp++, dp++) > *dp ^= *sp; > return dst; > } > " > Again, this is a extremely bad C Example, infested with (at least to me) > unclear pointer usage. (Luckily in Swift there are (or should be) no > pointers) Somewhere in this messy example, yes, a for-loop can be found. > Notice that the for-loop itself is relatively simple and straightforward. > Also, the fact that this for-loop deploys two value incrementors instead of > one, is in this particular context not really all that bad. > > > In my opinion, the Swift equivalent you offer, does not look much better: > > " > func blk_xor(dst: UnsafeMutablePointer<CChar>, src: > UnsafePointer<CChar>, len: Int) -> UnsafeMutablePointer<CChar> { > for i in 0..<len { > dst[i] ^= src[i] > } > return dst > } > > A search of github's Swift gists suggests the approach is used primarily by > those new to the language with minimal language skills and is abandoned as > language mastery is achieved. > " > Another subjective assumption and almost insulting for those, often with > years of experience, who deploy the classical for-loop intensively and really > knowing what they are doing. > > My conclusion: > Although the proposal has been accepted. I would like to see it withdrawn > because the arguments brought forward are highly subjective, > not thoroughly analyzed and in some cases even false. > Furthermore, a proposal should be based on facts, not assumptions. > > Kind Regards > TedvG. > > > > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
