Please… *please* let this lie. I understand that it will likely cause some specific cases to become more difficult but, on balance, it was a simplifying change. The syntax that we do have is clearer to those unfamiliar with programming idioms from other languages and people *are* familiar with other programming languages have the tools to construct whatever functionality they feel is missing from the provided tools.
TJ On Fri, Mar 18, 2016 at 5:19 PM, Ted F.A. van Gaalen via swift-evolution < swift-evolution@swift.org> wrote: > On Chris’s advice, I’ve spawned this into a new discussion topic, for > which the base could be > part of what I wrote in relation to SE-0007. > > > Hello Patrick > as I wrote: > > 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... > > I also find it of the most importance to keep Swift accessible for all > kinds of programmers > from starters to academic. > > Graig Federighi said > *We think it should be everywhere and used by everyone.* > > > I subscribe to that. > > > -TedvG > > > > > > On 18.03.2016, at 22:04, Patrick Gili <gili.patric...@gili-labs.com> > wrote: > > 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 < > swift-evolution@swift.org> 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 > 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 > >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution