<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="">Grüezi wohl Taras<div class=""><br class=""></div><div class="">you wrote:</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class="">I find it quite irritating that you keep repeating these untrue facts. Again: both for loops compile to exactly the same code. <br class=""></div></div></blockquote></div><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><br class=""></div></div></div><div class="">Alas, I don’t understand you irritation, </div><div class="">but it is your irritation, not mine.</div><div class=""><br class=""></div><div class="">Please note again, that “for ... in …” always has </div><div class="">some sort of collection type as its argument..</div><div class="">At run time, the content of a collection </div><div class="">is in most cases unpredictable.</div><div class="">Ergo: this implies that in these cases,</div><div class="">the compiler cannot optimize the collection </div><div class="">part of the “for … in …” statement out of the way. </div><div class="">In an attempt to overcome this restriction, </div><div class="">it would need to analyze all entities that have </div><div class="">influenced the content of the collection, </div><div class="">which is virtually impossible.</div><div class=""> </div><div class="">I do not understand your aversion against </div><div class="">the for loop I brought forward, as it does not </div><div class="">conflict at all with the “for ... in …” construct </div><div class="">and probably also does not stand in the way </div><div class="">of possible future extensions that could be </div><div class="">added to the "for in..” construct. </div><div class=""><br class=""></div><div class="">E.g. For similar reasons one could be irritated by </div><div class="">the brave attempts of some of us to supply </div><div class="">most peculiar variants of “Strides", seemingly,</div><div class="">at least as seen from my limited perspective,</div><div class="">to compensate the loss of the classical for-loop’s</div><div class="">facilities... </div><div class="">In spite of all this being very fascinating and </div><div class="">creative, to me, this effort is comparable with</div><div class="">trying to climb the Eiffel tower, equipped</div><div class="">with boxing gloves and diving fins.</div><div class="">it could irritate me.. However it does not,</div><div class="">for the mere reason that I do not fully </div><div class="">understand their motives and logical grounds...</div><div class="">Nevertheless, they might -or might not- </div><div class="">have good reasons to do so, as we no </div><div class="">doubt will find out sooner or later...</div><div class="">In any case, this does affect the collection-based</div><div class="">“for … in …” only, and has no impact on the </div><div class="">“for v from v1 to v2 by vstep” </div><div class="">that I am proposing. </div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><div class=""><div><blockquote type="cite" class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><div class="">Collection-based for loop can express exactly the same semantics, so why do you need a new construct when you already have a perfectly good one to do the job? </div></div></div></blockquote></div></div></div><div><br class=""></div><div>For the simple reason that there are no collections involved: </div><div>I have very clearly described and motivated it. </div><div>Please read it again, thank you.</div><div><br class=""></div><div>By the way, it is not a new construct as it has been</div><div>existing for decades.</div><div class=""><br class=""></div><div class="">I took the liberty to read about you on the internet. Interesting.</div><div class=""><br class=""></div><div class="">I’ve read that you have a degree in linguistics, </div><div class="">which makes me assume that of all people, </div><div class="">you’d understand that in most languages </div><div class="">there are many different ways to express something,</div><div class="">and that the way to express or say something </div><div class="">is mostly determined by contextual aspects... </div><div class="">So in the light of this very specific knowledge</div><div class="">that you have, I fail to understand what your</div><div class="">objections are against the presence of </div><div class="">two slightly different for-loop variants</div><div class="">that can co-exist easily and are effective,</div><div class="">each in its own different context? </div><div class=""><br class=""></div><div class="">Last but not least, you might find this interesting:</div><div class="">(although I am almost sure you have read it before)</div><div class=""><br class=""></div><div class=""><a href="http://blog.oxforddictionaries.com/2014/09/george-orwell-newspeak/" class="">http://blog.oxforddictionaries.com/2014/09/george-orwell-newspeak/</a></div><div class=""><br class=""></div><div class="">and then most particularly in this text: </div><div class=""><br class=""></div><div class="">“Newspeak goals and real-world ramifications”</div><div class=""><br class=""></div><div class="">I cannot completely clear myself from the association</div><div class="">of this with the removal of certain Swift language </div><div class="">elements..</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Met vriendelijke groeten.</div><div class="">TedvG</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""> </div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 31.03.2016, at 10:11, Taras Zakharko <<a href="mailto:taras.zakharko@googlemail.com" class="">taras.zakharko@googlemail.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 30 Mar 2016, at 22:05, 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="">Again I need to emphasize very strongly that this for-loop really </div><div class="">has absolutely </div><div class=""> nothing, nada, zilch, niente, nichts, niets, niks, rien, zero, nenio,</div><div class="">to do with the: </div><div class=""><br class=""></div><div class="">for i in stride(…. </div><div class=""><br class=""></div><div class="">or any other for in… variant working with collections.</div></div></div></blockquote><div class=""><br class=""></div><div class="">Of course it does. Collection-based for loop can express exactly the same semantics, so why do you need a new construct when you already have a perfectly good one to do the job? </div></div></div></div></blockquote><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=""><br class=""></div></div></div></blockquote><div><br class=""></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=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="margin: 0px; font-size: 16px; line-height: normal; font-family: Menlo;" class=""><br class=""></div><div style="margin: 0px; font-size: 16px; line-height: normal; font-family: Menlo;" class=""><div style="font-family: Helvetica; font-size: 14px;" class="">but, once again - </div><div style="font-family: Helvetica; font-size: 14px;" class="">provided you don’t want to do other operations</div><div style="font-family: Helvetica; font-size: 14px;" class="">on the generated collection before iterating - </div><div style="font-family: Helvetica; font-size: 14px;" class="">a collection is used here totally unnecessary, </div><div style="font-family: Helvetica; font-size: 14px;" class="">which puts a burden on performance because the contents </div><div style="font-family: Helvetica; font-size: 14px;" class="">of a collection are unpredictable </div></div></div></blockquote><div class=""><br class=""></div>I find it quite irritating that you keep repeating these untrue facts. Again: both for loops compile to exactly the same code. <br class=""><div class=""><br class=""></div><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="margin: 0px; font-size: 16px; line-height: normal; font-family: Menlo;" class=""><div style="font-family: Helvetica; font-size: 14px;" class="">It is also tedious to write and (as a matter of my personal taste) downright ugly.</div></div></div></blockquote><div class=""><br class=""></div><div class="">Right, because </div><div class=""><br class=""></div><div class=""> for d in stride(from:10, to: 5, by: 0-.1, tolerance: 0.01) </div><div class=""><br class=""></div><div class="">is that much more tedious to write than what you propose</div><div class=""><br class=""></div><div class="">Best, </div><div class=""><br class=""></div><div class=""> Taras</div><div class=""><br class=""></div><div class=""><br class=""></div></div></div></div></blockquote></div><br class=""></div></body></html>