Hello Chris, Thank you, I know that and agree with you asking me to follow the usual path in Swift-evolution, of course.
I am currently working on a proposal for a new for-loop variant: for v from v1 to v2 [by vstep] [tolerance vtol ] // in [] is optional here for numerical values. As you might have noticed I already wrote something about that > a week a go. I don’t want the classical for-loop back per se, but simply want to bring forward an appropriate equivalent which fits better in the Swift environment. I will start a new discussion for this topic as you recommend, next week. The issue that I have with SE-0007 that it is in my opinion not professional, for reasons I have mentioned in my conclusion at the end. That is the main reason I brought it forward. Kind Regards -TedvG > On 18.03.2016, at 22:18, Chris Lattner <clatt...@apple.com> wrote: > > Hi Ted, > > I know you are trying to be helpful here, but this proposal has already been > accepted and implemented. Keep in mind that while the proposal itself is > germane and important, it is the community discussion around it, and > ultimately the core team decision that led to its removal. > > If you would like to see C style for loops brought back, the proper > procedural way to do this would be to start a new discussion (which would > lead to a formal proposal) to add them to swift. This should include clear > and cogent arguments for why the feature is worth adding to > swift-that-currently-does-not-have-it, rather than arguing that an accepted > proposal has issues. > > -Chris > > On Mar 18, 2016, at 1:28 PM, Ted F.A. van Gaalen <tedvgios...@gmail.com > <mailto:tedvgios...@gmail.com>> wrote: > >> Yes, I am back because I should not leave because I might be afraid for >> negative reactions on what I write. I try to write and respond as civilized >> as >> possible and never intended as personal, unless it really is. However there >> was one >> person taking wat I wrote personally so I wrote back very friendly that it >> was not. >> No response, twice. It is not very nice to be ignored when you really make a >> real effort >> trying to resolve a misunderstanding. It upset me. that's why I left. >> Needed time to recover. The problem lies by The Other One, no longer by me. >> Ok, sorry for overreacting. >> >> Please ==snip== the above paragraph (and this line) when responding so that >> it doesn't propagate through >> Swift-evolution. It doesn't belong there after this. Thanks. >> >> 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