Hello T.J. It will be an addition, not a change. The for- statement I will bring forward does not change the existing for-in... at all or any other language element.
-TedvG > On 19 Mar 2016, at 00:55, T.J. Usiyan <[email protected]> wrote: > > 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 >> <[email protected]> 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 <[email protected]> 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 >>>> <[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 >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
