<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><blockquote type="cite" class="">On Dec 19, 2015, at 2:24 PM, Brent Royal-Gordon <<a href="mailto:brent@architechies.com" class="">brent@architechies.com</a>> wrote:<br class=""><br class=""><blockquote type="cite" class=""><blockquote type="cite" class="">One practical reason is that interval.start must always be before interval.end, so this makes striding in reverse difficult.<br class=""></blockquote><br class="">We could declare that negative strides cause us to start at the end rather than at the start.<br class=""></blockquote><br class="">I've noticed in the past that the Swift standard library does not like to branch on sign. </blockquote><div class=""><br class=""></div><div class="">Almost. We simply don't like to branch :-)</div><br class=""><blockquote type="cite" class="">Of course, you could decide you just don't care in this particular case.<br class=""></blockquote><div class=""><br class=""></div>I'm willing to bet that in the vast majority of use cases, the sign of the stride can be known at compile-time and the branch can be eliminated.<div class=""><br class=""><blockquote type="cite" class=""><blockquote type="cite" class="">None of those syntaxes fly for me, I'm afraid. They all look like line noise (and some have precedence problems); I much prefer requiring a set of parentheses.<br class=""></blockquote><br class="">Even the free-function syntax?<br class=""></blockquote><div class=""><br class=""></div>I personally liked the original free-function syntax—"stride(from: -50, to: 50, by: 9)". When we got protocol extensions, we decided we'd <a href="https://swift.org/documentation/api-design-guidelines.html#general-conventions" class="">prefer methods everywhere except in a few special cases</a>, and this clearly falls outside those criteria. Then there are also people who feel very strongly that we should <a href="https://swift.org/documentation/api-design-guidelines.html#parameters" class="">avoid exposing an argument label on the first argument except in a few special cases</a>.</div><div class=""><br class=""></div><div class="">My first reaction to "stride(-60…60, by: 30)" is that you need some preposition between the verb and the first argument, though now that you ask again I can see reading "a...b" as "from a through b". </div><div class=""><br class=""></div><div class="">I view the syntactic unification of -60...60 and (-60...60).by(30) as a big win, and it doesn't conflict with any of our API guidelines, which is another plus. </div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""> for lat: CGFloat in stride(-60…60, by: 30) {<br class=""> print(lat)<br class=""> }<br class=""></blockquote></blockquote><br class="">One more alternative, which reads sort of backwards but has clear precedence, no line noise, and no free functions:<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>for lat: CGFloat in 30.strideOver(-60...60) {<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span>...<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>}<br class=""></blockquote><div class=""><br class=""></div>Others may differ, but asking 30 to stride over an interval really doesn't work for me, conceptually.</div><div class=""> <br class=""><div class="">-Dave<br class=""><br class=""><br class=""></div><br class=""></div></body></html>