I agree with Xiaodi that the use case given for the third stride style isn&#39;t compelling because you can simply increase the upper bound of the range that you&#39;re striding across. I&#39;d be curious to see a reason why you&#39;d want to stride past a bound and only stop one &quot;by&quot; past the bound. Seems like an esoteric function to include in stdlib.<br><br>Assuming there exists a compelling use case, I definitely like &quot;beyond&quot; or &quot;past&quot; better than &quot;through&quot;, as again the definition used for &quot;through&quot; in the proposal is not a numerical one. I think the current &quot;Strideable through&quot; style should keep its name. <br><br>The current &quot;Strideable to&quot; style is less ideally named, but I think it&#39;s more obvious than &quot;toward&quot; or any of the other proposed names in the updated gist for the reasons already discussed. Perhaps &quot;Strideable until&quot; would make more sense, as that better captures the finality of &quot;we&#39;re stopping when we see this upper bound&quot;.<br><br>Thanks,<br>Seth<br><div class="gmail_quote"><div dir="ltr">On Tue, Mar 1, 2016 at 1:20 PM Erica Sadun via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I don&#39;t think we&#39;re terribly far apart at this point. Looking forward to your thoughts<br>
and insights as you ponder.<br>
<br>
-- E<br>
<br>
&gt; On Mar 1, 2016, at 2:02 PM, Xiaodi Wu &lt;<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; I think I see where we&#39;ve not been connecting. You&#39;ve phrased the<br>
&gt; problem to be solved this way: &quot;this thing says it goes through and it<br>
&gt; doesn&#39;t, this thing says it goes to and it doesn&#39;t&quot;.<br>
&gt;<br>
&gt; I can see why you&#39;d see this as one single issue. You want the things<br>
&gt; to do what they say. And we very much still need the current function<br>
&gt; of stride(to:by:), so you rename that &#39;towards&#39;. That&#39;s how you end up<br>
&gt; with three stride styles instead of two.<br>
&gt;<br>
&gt; I haven&#39;t been thinking of it in that way. I see what you&#39;re proposing<br>
&gt; here as two discrete concerns:<br>
&gt; 1. You think the current things are poorly named. You propose<br>
&gt; different names for them.<br>
&gt; 2. You think we need a new third thing. You propose a new thing.<br>
&gt;<br>
&gt; My feedback, in a nutshell, is that I agree with you on the issue<br>
&gt; you&#39;ve identified in (1), but I quibble about the exact names--I&#39;m<br>
&gt; sure whatever is adopted will be great, though. (And thank you for<br>
&gt; taking the time to describe the problem and drive this!)<br>
&gt;<br>
&gt; However, I&#39;m not convinced that (2) is an issue. Reading your revised<br>
&gt; gist, I&#39;m still not convinced. I see one example about graph axes. As<br>
&gt; it happens, I&#39;m about to write some code to plot some stuff, and I<br>
&gt; haven&#39;t been regretting the lack of this third stride style. The<br>
&gt; reason is that I very much need to compute the top of the axis before<br>
&gt; I start striding through anything. Drawing axis tick marks comes quite<br>
&gt; a bit after computing the axis limits. And once I&#39;ve got the axis<br>
&gt; limits, I can use the second stride style. So, no convincing use case<br>
&gt; yet, imho. I still think we can address (1) without doing anything<br>
&gt; about (2).<br>
&gt;<br>
&gt;<br>
&gt; On Tue, Mar 1, 2016 at 2:29 PM, Erica Sadun &lt;<a href="mailto:erica@ericasadun.com" target="_blank">erica@ericasadun.com</a>&gt; wrote:<br>
&gt;&gt; On Mar 1, 2016, at 12:25 PM, Xiaodi Wu &lt;<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; To clarify, I am not troubled that stride(to:by:) as it is now doesn&#39;t<br>
&gt;&gt; pick up the sign. The point is that, if renamed to<br>
&gt;&gt; stride(towards:by:), the English meaning of &quot;towards&quot; implies that it<br>
&gt;&gt; would pick up the sign. It is a critique of the suggested renaming,<br>
&gt;&gt; not a critique of the algorithm being renamed.<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; Summarizing: &quot;Using `towards` suggests that the by value picks up the vector<br>
&gt;&gt; direction and<br>
&gt;&gt; can be misleading.<br>
&gt;&gt;<br>
&gt;&gt; Response:<br>
&gt;&gt;<br>
&gt;&gt; 1. yeah.<br>
&gt;&gt; 2. but no solution is going to be ideal.<br>
&gt;&gt; 3. alternatives: approaching, movingTowards, advancedTowards.  Included in<br>
&gt;&gt; the latest<br>
&gt;&gt; revision of the proposal.<br>
&gt;&gt;<br>
&gt;&gt; My big issues are &quot;this thing says it goes through and it doesn&#39;t, this<br>
&gt;&gt; thing says it goes to and it doesn&#39;t&quot;.<br>
&gt;&gt; So long as those are fixed reasonably well, I am happy, even without the<br>
&gt;&gt; naming being perfect.<br>
&gt;&gt;<br>
&gt;&gt; I must misunderstand what it is you tweaked. You still write that the<br>
&gt;&gt; other proposal doesn&#39;t remove the need for manual epsilon adjustment?<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; In order to separate this into two proposals, I had to make sure they<br>
&gt;&gt; weren&#39;t depending on each other.<br>
&gt;&gt; So this proposal *only* addresses the semantic mismatch I described 4 lines<br>
&gt;&gt; up.<br>
&gt;&gt;<br>
&gt;&gt; Manual epsilon adjustment is simply a floating point thing, and is discussed<br>
&gt;&gt; at length in the<br>
&gt;&gt; other proposal (Again, keep refreshing gist.github because both are works in<br>
&gt;&gt; progress.)<br>
&gt;&gt;<br>
&gt;&gt; [first...last] subsumes [from...through]. You might call this a..&gt;b<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; I understand that you believe this makes the behavior of &quot;through&quot;<br>
&gt;&gt; more sensible. I could even agree. But do we need this third stride<br>
&gt;&gt; style, whatever it&#39;s called? Essentially, my question is: besides the<br>
&gt;&gt; issue of epsilon adjustments, when have you encountered a case in your<br>
&gt;&gt; code where you&#39;ve needed to stride beyond the end point?<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; First, I renamed it with the two options a...&gt;b, a..&gt;=b and a..=&gt;b to<br>
&gt;&gt; suggest &quot;reach or greater&quot;.<br>
&gt;&gt;<br>
&gt;&gt; Second, yes, and I added a big new section on canonical use cases.<br>
&gt;&gt;<br>
&gt;&gt; -- E<br>
&gt;&gt;<br>
<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div>