<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=""><div class="">Hi Taras</div><div class=""><br class=""></div><div class="">I’ve watched the WWDC15 video about Swift compiler optimization, read some more</div><div class="">in depth material about it. It is probably advanced in many aspects of optimization.</div><div class="">So, you might be correct to assume that the compiler can optimize</div><div class=""><blockquote type="cite" class=""> for(int i = x0; i<x1; i++)<br class=""></blockquote>(also with floats)</div><div class="">and perhaps also for a collection based variant such as:</div><div class=""><br class=""></div><div class=""> for v in stride(from -8.4, to: 3.2, by 0.1)</div><div class=""><br class=""></div><div class="">In any case, I don’t know for sure. I am not a compiler specialist</div><div class="">Therefore I void our argument about whether or not the compiler</div><div class="">can do enough magic to get it right.</div><div class=""><br class=""></div><div class=""><div class="">Still, there are no good alternatives for the many advanced possibilities</div><div class="">which traditional for loop offers.</div></div><div class="">E.g.</div><div class="">In the Apple TV app I am currently working on I had to refactor</div><div class="">my for ;; loops with reversing floats with step values to “while” loops!</div><div class=""><br class=""></div><div class="">So, to me the best option is still to bring the for ;; back</div><div class="">or to make a new Swift equivalent for it as described here again.</div><div class=""><br class=""></div><div class=""><div class="" style="margin: 0px; font-size: 16px; line-height: normal; font-family: Menlo;"><span class="" style="font-variant-ligatures: no-common-ligatures; color: rgb(187, 44, 162);">for</span><span class="" style="font-variant-ligatures: no-common-ligatures;"> d </span><span class="" style="font-variant-ligatures: no-common-ligatures; color: rgb(187, 44, 162);">from</span><span class="" style="font-variant-ligatures: no-common-ligatures;"> </span><span class="" style="font-variant-ligatures: no-common-ligatures; color: rgb(39, 42, 216);">10.0 </span><span class="" style="color: rgb(187, 44, 162);">to </span><span class="" style="color: rgb(39, 42, 216);">5.0 </span><span class="" style="color: rgb(187, 44, 162);">by </span><span class="" style="color: rgb(39, 42, 216);">-0.1</span><span class="" style="color: rgb(187, 44, 162);"> </span><span class="" style="color: rgb(187, 44, 162);">tolerance </span><span class="" style="color: rgb(39, 42, 216);">0.01 //tolerance is optional</span></div><div class="" style="margin: 0px; font-size: 16px; line-height: normal; font-family: Menlo;">{</div><div class="" style="margin: 0px; font-size: 16px; line-height: normal; font-family: Menlo;"><span class="" style="font-variant-ligatures: no-common-ligatures;"> </span><span class="" style="font-variant-ligatures: no-common-ligatures; color: rgb(61, 29, 129);">print</span><span class="" style="font-variant-ligatures: no-common-ligatures;">(d)</span></div><div class="" style="margin: 0px; font-size: 16px; line-height: normal; font-family: Menlo;"><span class="" style="font-variant-ligatures: no-common-ligatures;">}</span></div><div class=""><span class="" style="font-variant-ligatures: no-common-ligatures;"><div class="" style="margin: 0px; font-size: 16px; line-height: normal; font-family: Menlo; color: rgb(0, 132, 0);"> </div></span></div></div><div class="">-=straight from the front line: =-</div><div class="">Because my music maker apps RavelNotes and RavelNotesBasic are still</div><div class="">for the most part Objective C sources, I only have to do this in the Swift</div><div class="">sources of my apps. </div><div class="">Now, I have to refactor (only) about 10 for ;; loops to for in.. loops</div><div class="">and have to convert about 10 ++ to += things. </div><div class="">Luckily, they are all for-loops with integers, so the refactoring </div><div class="">itself took less than hour, that was no problem.</div><div class="">However, now I have to thoroughly retest everything again, </div><div class="">costing me several days or so, before I can submit a </div><div class="">new release of my apps to the app store!!</div><div class="">I am still lucky not to work for a company and </div><div class="">having to convert a lot more source code.</div><div class="">I was considering converting more ObjC to Swift, put</div><div class="">put this on halt until Swift stabilizes.</div><div class=""><br class=""></div><div class="">Now, like me, many programmers have to do a </div><div class=""><div class="">whole lot of nasty for-loop refactoring!</div><div class=""><br class=""></div></div><div class="">Therefore, excuses moi, but currently I can’t help </div><div class="">being in a state just somewhere between </div><div class="">annoyed and aggravated because I am unnecessarily </div><div class="">waisting lots of time due to some puritan obsessed </div><div class="">decisions, partially from some people with high </div><div class="">theoretical knowledge but very little practical experience, </div><div class="">or so it seems. </div><div class="">Don’t get me wrong: </div><div class="">Swift is great, e.g. i like the new protocol developments, and of course I understand </div><div class="">(and support) that one needs to be very thoughtful about components of the language. </div><div class="">But one should be pragmatic as well. </div><div class=""> -==- </div><div class=""><br class=""></div><div class="">You also wrote:</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class="">In case I didn’t explain my reasoning clear enough, here is another attempt. Swift already has a very powerful, compact tool that offers a strict superset of the iteration semantics.</blockquote><div class="">That is not (yet) the case, let alone a superset!</div><div class=""><br class=""></div><blockquote type="cite" class=""> I simply see no purpose into making the language more verbose and complicated for no particular gain. </blockquote></div><div class="">It doesn’t make the language more complicated, rather, the reverse is true.</div><div class="">If you want a less verbose language, learn APL, or J.</div><div class="">APL proves unintentionally the inverse relation between “verbose”and “complicated” :o) </div><div class=""><br class=""></div><div class=""><blockquote type="cite" class="">What you do is argue for having two different syntactic styles for accomplishing exactly the same thing, </blockquote><blockquote type="cite" class="">simply on the grounds of your personal dislike of one of them. <br class=""></blockquote><div class="">It is not at all personal dislike, it is many years of die-hard experience </div><div class="">with a multitude of programming languages and systems.</div><div class="">I don’t think in emotional terms about programming constructs but</div><div class="">solely about practical implications, usefulness, reliably and so on.</div></div><div class=""><br class=""></div><div class="">I assume this difference of opinion will remain...</div><div class=""><br class=""></div><div class=""> -----</div><div class="">Coincidentally, today John Heerema, described here on swift-evolution </div><div class="">exactly my point of view on these matters based on facts. </div><div class="">read his text please. Thank you.</div><div class=""> -----</div><div class="">I hope I am not too unfriendly here, Nothing personal. </div><div class="">If I am in Zürich again it would be nice to discuss this with a beer. </div><div class="">Although not so far from here, currently my finances prevent this.</div><div class=""><br class=""></div><div class="">Kind regards</div><div class="">Ted</div><div class=""><div class=""><a href="http://www.ravelnotes.com" class="">www.ravelnotes.com</a></div></div><div class=""><br class=""></div><div class=""><div class=""> == The problem is not what you add to a programming language</div><div class=""> == but what you remove!</div><div class=""> </div><div class=""></div></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><br class=""><div><blockquote type="cite" class=""><div class="">On 31.03.2016, at 14:59, Taras Zakharko <<a href="mailto:taras.zakharko@uzh.ch" class="">taras.zakharko@uzh.ch</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><br class=""><blockquote type="cite" class="">On 31 Mar 2016, at 14:12, Ted F.A. van Gaalen <<a href="mailto:tedvgiosdev@gmail.com" class="">tedvgiosdev@gmail.com</a>> wrote:<br class=""><br class="">Alas, I don’t understand you irritation, <br class="">but it is your irritation, not mine.<br class=""></blockquote><br class="">Well, its quite simple: we are having a discussion here. You are claiming that the collection-based iteration is inherently slower than a classical numerical loop. This is incorrect. I have even sent around some C code that uses different abstractions and shown that it compiles to the same machine code. Yet you are consistently ignoring this. <br class=""><br class=""><blockquote type="cite" class="">Please note again, that “for ... in …” always has <br class="">some sort of collection type as its argument..<br class="">At run time, the content of a collection <br class="">is in most cases unpredictable.<br class=""></blockquote><br class="">Again, incorrect. The simple collections that are relevant to this discussion are based on trivial iterators that can be statically dispatched and inlined by the compiler. They can potentially even be unrolled (although I doubt that Swift optimiser does this kind of optimisation currently). Again, the difference between<br class=""><br class="">for(int i = x0; i<x1; i++)<br class=""><br class="">and<br class=""><br class="">for(int i = iterator->next(); !iterator->endReached, int i = iterator->next()) <br class=""><br class="">is just one level of indirection. If the value of iterator->next() is available at the compile time and the compiler can safely assume that the iterator has a unique reference, the code can be inlined, producing the same loop as above<br class=""><br class=""><blockquote type="cite" class="">E.g. For similar reasons one could be irritated by <br class="">the brave attempts of some of us to supply <br class="">most peculiar variants of “Strides", seemingly,<br class="">at least as seen from my limited perspective,<br class="">to compensate the loss of the classical for-loop’s<br class="">facilities… <br class=""></blockquote><br class="">I am not at all a fan of the stride() method because they are weird to read. However, a stride() global function will do the job just fine, as shown by the example of such languages as R and Python, which are used quite prominently in the numerical domain (there the functions are called seq() and range() )<br class=""><br class=""><blockquote type="cite" class="">For the simple reason that there are no collections involved: <br class="">I have very clearly described and motivated it. <br class=""></blockquote><br class="">Your description clearly involve numerical sequences. So they perfectly well fall into the domain of sequence-based iteration. <br class=""><br class=""><blockquote type="cite" class="">I took the liberty to read about you on the internet. Interesting.<br class=""></blockquote><br class="">Thank you, its very flattering :) <br class=""><br class=""><blockquote type="cite" class="">I fail to understand what your<br class="">objections are against the presence of <br class="">two slightly different for-loop variants<br class="">that can co-exist easily and are effective,<br class="">each in its own different context? <br class=""></blockquote><br class="">In case I didn’t explain my reasoning clear enough, here is another attempt. Swift already has a very powerful, compact tool that offers a strict superset of the iteration semantics. I simply see no purpose into making the language more verbose and complicated for no particular gain. What you do is argue for having two different syntactic styles for accomplishing exactly the same thing, simply on the grounds of your personal dislike of one of them. <br class=""><br class="">Best, <br class=""><br class=""> Taras</div></div></blockquote></div><br class=""></body></html>