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