<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Mar 1, 2016, at 1:54 AM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" class="">xiaodi.wu@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">It's so nice to see such care devoted to clarifying these existing<br class="">names. I agree with the premise that stride(to:by:) and<br class="">stride(through:by:) are poorly named, but I'd like to make two<br class="">critiques of this proposal--<br class=""><br class="">Critique 1:<br class=""><br class="">The basic distinction between the two current stride styles is that<br class="">one is inclusive and the other is exclusive of the end value. I agree<br class="">with you that "to" doesn't imply an exclusive end value, but "towards"<br class="">doesn't imply that the parameter is any sort of end value at<br class="">all--rather, it implies just a direction (or as you quote from the<br class="">NOAD, getting close or closer).<br class=""><br class="">Two implications:<br class=""><br class="">First, if I stride from 10 towards 0 by 1, by the plain English<br class="">meaning of the word "towards", I would expect to obtain 10, 9, 8, 7,<br class="">6, etc. If we simply rename stride(to:by:) to stride(towards:by:), I</div></div></blockquote><blockquote type="cite" class=""><div class=""><div class="">would not get that result. By contrast, it makes sense from the<br class="">current name that stride(to:by:) attempts to increment using the `by`<br class="">parameter without considering whether the end value is greater than or<br class="">less than the start value; if you can't get from here "to" there by<br class="">such increments, too bad!<br class=""></div></div></blockquote><div><br class=""></div><div>Do you want the stride to pick up the sign automatically? Instead of </div><div><br class=""></div><div><font face="Menlo" class="">print(Array(10.stride(to: 0, by: -1))) // [10, 9, 8, 7, 6, 5, 4, 3, 2, 1], current Swift</font></div><div><br class=""></div><div>have</div><div><br class=""></div><div><div><font face="Menlo" class="">print(Array(10.stride(to: 0, by: 1))) // [10, 9, 8, 7, 6, 5, 4, 3, 2, 1], adjusted sign</font></div><div><br class=""></div><div>Or am I missing your point of "if I stride from 10 towards 0 by 1"?</div><div><br class=""></div><div><br class=""></div></div><blockquote type="cite" class=""><div class=""><div class="">Second, if I stride from 0 towards 10 by 1 (in the English language,<br class="">not in Swift), I may or may not stop short of 10 itself. That is,<br class="">whether "towards" is inclusive or exclusive of the end value can't be<br class="">inferred from the meaning of the word; after all, if I'm making<br class="">strides towards a goal, I do intend to reach it, or at least that's<br class="">what I tell people when they ask how my PhD is going...<br class=""></div></div></blockquote><div><br class=""></div><div>I'm searching for a word that means "in the direction of but never reaching". </div><div><br class=""></div><div><font face="Menlo" class="">print(Array(10.stride(to: 0, by: -1))) // [10, 9, 8, 7, 6, 5, 4, 3, 2, 1], current Swift</font></div><div class=""><font face="Menlo" class=""><br class=""></font></div>This never reaches 0.</div><div><br class=""></div><div><br class=""><blockquote type="cite" class=""><div class=""><div class="">Generalizing from the word "towards", I don't know that any two<br class="">prepositions in the English language can be used unambiguously to<br class="">convey the distinction between inclusive and exclusive end values.<br class="">Although, on some additional thought--if I had to suggest a<br class="">preposition, perhaps "until" or "till" would be more apt than<br class="">"towards".<br class=""></div></div></blockquote><div><br class=""></div><div>`until` to me suggests reaching the end-point.</div><br class=""><blockquote type="cite" class=""><div class=""><div class="">The saving grace of "to" and "through" in the current situation is<br class="">that the latter seems intuitively to go further than the former, </div></div></blockquote><div><br class=""></div><div>Quite often, it doesn't really:</div><div><br class=""></div><div><div><font face="Menlo" class="">print(Array(1.stride(to:10, by: 8))) // [1, 9]</font></div><div><font face="Menlo" class="">print(Array(1.stride(through:10, by: 8))) // [1, 9]</font></div><div><br class=""></div></div><br class=""><blockquote type="cite" class=""><div class=""><div class="">and<br class="">if one deduces by analogy with the range operators that one of these<br class="">must exclude the end value and the other include it, then the two<br class="">names must mean what they do today. With three stride styles and three<br class="">prepositions, but only two range operators, this intuition is broken,<br class="">while the prepositions may not get much clearer (though I must admit<br class="">that your proposed use of "to" is an improvement).<br class=""><br class="">Critique 2:<br class=""><br class="">The original motivation behind your twin proposals was the epsilon<br class="">adjustment necessary for floating point end values. Your other<br class="">proposal fixes an issue with accumulated errors but doesn't solve the<br class="">need for an epsilon adjustment.</div></div></blockquote><div><br class=""></div><div>Actually, I've tweaked it this morning to take care of that. Reload: <a href="https://gist.github.com/erica/cf50f3dc54bb3a090933" class="">https://gist.github.com/erica/cf50f3dc54bb3a090933</a></div><br class=""><blockquote type="cite" class=""><div class=""><div class=""> Here, you propose adding a third<br class="">stride style to solve that problem</div></div></blockquote><div><br class=""></div><div>It's really solving the 1/10/by 8 problem more than the 2.0 problem. Which is a big reason why I even</div><div>brought up the issue of separating the proposals in the first place. To me, the following just doesn't make</div><div>sense:</div><div><br class=""></div><div><div><font face="Menlo" class="">print(Array(1.stride(through:10, by: 8))) // [1, 9]</font></div><div class=""><font face="Menlo" class=""><br class=""></font></div></div><br class=""><blockquote type="cite" class=""><div class=""><div class="">, along the way shuffling the naming<br class="">of the existing stride styles. Since you haven't presented other use<br class="">cases for that third stride style here, and you haven't listed<br class="">alternatives considered for solving the original motivating problem<br class="">(i.e. epsilon adjustment), let me propose one alternative:<br class=""></div></div></blockquote><div><br class=""></div>Canonical use-cases for all three styles:</div><div><br class=""></div><div><b class="">1 towards 5 by 1: [1, 2, 3, 4] </b></div><div>This style mimics <b class="">a..<b </b>but allows non-unit and negative progressions</div><div><br class=""></div><div><b class="">1 to 5 by 1: [1, 2, 3, 4, 5]</b></div><div>This style mimics a...b but allows non-unit and negative progressions</div><div><br class=""></div><div><b class="">1 through 10 by 8: [1, 9, 17]</b></div><div>This style ensures a non-unit and negative progression that passes to or through the final value, </div><div>ensuring that the range of the progression fully includes the range of the from and to values:</div><div>[first...last] subsumes [from...through]. You might call this a..>b</div><div><br class=""></div><div><blockquote type="cite" class=""><div class=""><div class="">Keep the naming of stride styles as-is (inapt as they may be), and for<br class="">floating point end values make stride(through: aNumber, by: something)<br class="">equivalent to stride(to: theNextLargestRepresentableNumber, by:<br class="">somethingPositive) or stride(to: theNextSmallestRepresentableNumber,<br class="">by: somethingNegative). Would that solve your original issue<br class="">adequately?<br class=""><br class="">Alternatively, if there are lots of examples that can be envisioned<br class="">for this third stride style, would the same examples suggest perhaps<br class="">that `..>` might be a useful third range operator? <br class=""></div></div></blockquote><br class=""></div><div>I like that quite a lot actually.</div><div><br class=""></div><br class=""></body></html>