<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hi Austin, thank you, please see inline.<br class=""><div><blockquote type="cite" class=""><div class="">On 28.07.2016, at 19:33, Austin Zheng <<a href="mailto:austinzheng@gmail.com" class="">austinzheng@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jul 28, 2016, at 10:19 AM, Ted F.A. van Gaalen via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div class=""> -= Maybe it’s not too late =- </div><div class="">For the moment the classical for ;; could simply </div><div class="">remain activated (Yes) in 3.0. because: </div></div></div></blockquote><div class=""><br class=""></div><div class="">I don't understand why you keep on complaining about this.</div></div></div></div></blockquote><div>? </div>I have explained this many times before, didn’t I? </div><div><br class=""></div><div>Its removal causes a very crucial limitation/change in the way </div><div>one writes programs, So writing about this for;; subject is</div><div>very, very different from long discussions like those about </div><div>allowing a comma at the end of a list or not…</div><div>because removing the for;; has a very heavy impact.</div><div><br class=""></div><div>Furthermore, IMHO the decision to remove the for;; was based</div><div>on very subjective loose and partly irrelevant criteria.</div><div><br class=""></div><div>For example the suggestion, that experienced</div><div>programmer will refrain from using the for;;</div><div>was ridiculous. It’s a bit like assuming that a technicians</div><div>will not use a screw drivers anymore..</div><div><br class=""></div><div>I’ve wrote about this extensively before.</div><div> </div><div>Just read that proposal to remove </div><div>the for;; and for that matter also the ++ and — again.. </div><div>Albeit a bit understandable: It was one of the first proposals, </div><div>written in a time when everything had just started..</div><div><br class=""></div><div>Personally, for my apps, removing the for;; results in lots of </div><div>otherwise unnecessary time converting at least ten source files, </div><div>typically containing about five for;; loops each, nested ones also. </div><div><br class=""></div><div>Automagic conversion is not possible also because many of </div><div>these iterations are with floating point numbers and also </div><div>run backwards.let alone with decrementing steps.</div><div><br class=""></div><div>In my Apple TV 3D SceneKit based app under construction</div><div>these are for;; with floats, which have to be replaced by do-while constructs..</div><div><br class=""></div><div>In all of my apps (i am a pour lonesome developer :o) </div><div>I have to test all of this again and again to make sure </div><div>my apps work flawlessly without errors again, as they do now.</div><div>(see RavelNotes and RavelNotesBasic) </div><div>These apps are quite complex, changing and testing</div><div>these is not that easy.</div><div><br class=""></div><div>Ergo: as a law of steel: </div><div>One should *never* introduce backward breaking changes!</div><div><br class=""></div><div>So I am very glad Ted Kremenek came forward with this</div><div>module based different version compilation option.</div><div>It seems to be a reasonable alternative. </div><div><br class=""></div><div>If not, I would have dropped Swift soon and look for another</div><div>solution to produce my apps. However, this would be very regrettable.</div><div>because I really love Swift. I wouldn’t be here if I didn’t !</div><div><br class=""></div><div>I was quite happy with Swift 2. It had all the things I tend to expect</div><div>from a state of the art programming language. very cool.</div><div>and also eagerly waiting for *additive* changes and improvements.</div><div><br class=""></div><div><br class=""></div><div>@Craig: </div><div>When Swift was presented and its use encouraged by you, Craig, on the WWDC, </div><div>it was not supposed to be in a *beta stage* ! At least, it was my impression</div><div>that it was no longer in beta stage and that it was OK to use Swift for</div><div>production, no one told otherwise, if I remember correctly.</div><div><br class=""></div><div>And so I embraced Swift immediately, me being mostly an early adapter </div><div> (even when being in IT since 1978 or so, or maybe rather because of that!) </div><div> assuming that it was solid and a safe bet to use it in a production environment. </div><div><br class=""></div><div>However, IMHO, it has been virtually in a beta stage until now, </div><div>simply because, things were and are still changing!.</div><div>Yes, of course I do expect improvements, however they should be</div><div>additive, not code breaking changes.</div><div><br class=""></div><div>I also do understand and don’t underestimate the motion with new languages. </div><div class=""><br class=""></div><div><br class=""></div><div>If I had known all this before, I would have remained programming</div><div>my apps in Objective C until a more solid version came along. </div><div>In the mean time, yes, of course, I would have played with it and studying it</div><div>sideways, and take part and listening in this forum. </div><div><br class=""></div><div>And, maybe then I would have enough faith in 3.0 that is to </div><div>use Swift 3.0 and higher fully in a production environment.</div><div>And don’t get me wrong, I like Swift very much it really </div><div>is a very advanced development.</div><div><br class=""></div><div>And then another thing, well, maybe you’d</div><div>think that I am whining a bit, but try to see it this way:</div><div>Most things in Swift are OK and even superb, so I don’t</div><div>need to write about these! What remains then is just to </div><div>write about the thing’s I don’t like or which could be</div><div>improved. This might give the impression that I am just </div><div>complaining, note however, nothing is farther from the truth. </div><div><div><br class=""></div><div>( because we just write, which is a very limited form</div><div>of human communication being a lot different then sitting</div><div>around a round table (hmm that reminds me of something :o)</div><div class="">laughing and drinking coffee. I you’d wish to change that</div><div class="">send me a ticket to San Francisco or so. :o) </div><div class=""><br class=""></div></div><div><br class=""></div><div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class=""><br class=""></div><div class="">For the record, I too think getting rid of the C-style for loop was a mistake, </div></div></div></div></blockquote><div>Yes it is. Well, then maybe you also could perhaps have made more effort</div><div>to keep the for;; and other colleagues too that think likewise? </div><div>Or in the near future, to support my upcoming proposal? </div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class="">and there are a number of other proposals whose outcomes are not ones I would have personally preferred.</div></div></div></div></blockquote>Of course, I realize that as well, that goes for me too. </div><div><span style="color: rgb(0, 102, 33); font-family: arial, sans-serif; white-space: nowrap; background-color: rgb(255, 255, 255);" class=""><a href="https://www" class="">https://www</a>.</span><b style="color: rgb(0, 102, 33); font-family: arial, sans-serif; white-space: nowrap;" class="">you</b><span style="color: rgb(0, 102, 33); font-family: arial, sans-serif; white-space: nowrap; background-color: rgb(255, 255, 255);" class=""><a href="http://tube.com/watch?v=7S94ohyErSw" class="">tube.com/watch?v=7S94ohyErSw</a></span></div><div>:o)<br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class=""><br class=""></div><div class="">However,</div><div class=""><br class=""></div><div class="">1. There is a well-defined process through which all changes to the Swift language must go, laid out in the swift-evolution repository's documentation from the first day Swift became an open-source project.</div></div></div></div></blockquote>I know that, and that’s why I will make a proposal after 3.0 to reinstate the classical for loop. </div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class="">2. That process includes feedback and review from both the community and the Swift core engineers, and often multiple rounds of discussion.</div></div></div></div></blockquote>Agreed, but I arrived much later..</div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class="">3. The process doesn't work if we disregard its outcomes simply because we don't like them, or if we allow interminable chains of back-and-forth proposals because people on one side of issue X simply cannot accept a particular decision.</div></div></div></div></blockquote>Obviously, however, if a proposal, due to later insights, is wrong or conflicting is should be discussable to drop, correct or replace it.<br class=""> <br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class=""><br class=""></div><div class="">The technical aspects of the C-style for loop and its proposed replacements have already been discussed <i class="">ad nauseam</i> on this list and in other places, so I won't touch on them.</div></div></div></div></blockquote>true, I’ve had my share in these too. what remains now for me to do is, </div><div> to propose a reinstatement of the for ;; (as in Go) after 3.0</div><div>I’ll do that. </div><div><br class=""></div><div>Met vriendelijke groeten</div><div>from a Dutch professional somehow landed in Germany :o)</div><div>TedvG</div><div><a href="http://www.tedvg.com" class="">www.tedvg.com</a></div><div><a href="http://www.ravelnotes.com" class="">www.ravelnotes.com</a></div><div><a href="http://www.speyer.de" class="">www.speyer.de</a></div><div><br class=""></div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class=""><i class=""><br class=""></i></div><div class="">Best regards,</div><div class=""><i class="">Austin </i> </div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""> </div><div class=""> - It doesn’t conflict at all with all other language elements,</div></div></div></blockquote></div></div></div></blockquote>YEs!<br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""></div></div></blockquote></div><br class=""></body></html>