[swift-evolution] [Proposal] Conventionalizing stride semantics

[Erica Sadun]

I don't think we're terribly far apart at this point. Looking forward to your thoughts 
and insights as you ponder.

-- E

> On Mar 1, 2016, at 2:02 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
> 
> I think I see where we've not been connecting. You've phrased the
> problem to be solved this way: "this thing says it goes through and it
> doesn't, this thing says it goes to and it doesn't".
> 
> I can see why you'd see this as one single issue. You want the things
> to do what they say. And we very much still need the current function
> of stride(to:by:), so you rename that 'towards'. That's how you end up
> with three stride styles instead of two.
> 
> I haven't been thinking of it in that way. I see what you're proposing
> here as two discrete concerns:
> 1. You think the current things are poorly named. You propose
> different names for them.
> 2. You think we need a new third thing. You propose a new thing.
> 
> My feedback, in a nutshell, is that I agree with you on the issue
> you've identified in (1), but I quibble about the exact names--I'm
> sure whatever is adopted will be great, though. (And thank you for
> taking the time to describe the problem and drive this!)
> 
> However, I'm not convinced that (2) is an issue. Reading your revised
> gist, I'm still not convinced. I see one example about graph axes. As
> it happens, I'm about to write some code to plot some stuff, and I
> haven't been regretting the lack of this third stride style. The
> reason is that I very much need to compute the top of the axis before
> I start striding through anything. Drawing axis tick marks comes quite
> a bit after computing the axis limits. And once I've got the axis
> limits, I can use the second stride style. So, no convincing use case
> yet, imho. I still think we can address (1) without doing anything
> about (2).
> 
> 
> On Tue, Mar 1, 2016 at 2:29 PM, Erica Sadun <erica at ericasadun.com> wrote:
>> On Mar 1, 2016, at 12:25 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>> 
>> To clarify, I am not troubled that stride(to:by:) as it is now doesn't
>> pick up the sign. The point is that, if renamed to
>> stride(towards:by:), the English meaning of "towards" implies that it
>> would pick up the sign. It is a critique of the suggested renaming,
>> not a critique of the algorithm being renamed.
>> 
>> 
>> Summarizing: "Using `towards` suggests that the by value picks up the vector
>> direction and
>> can be misleading.
>> 
>> Response:
>> 
>> 1. yeah.
>> 2. but no solution is going to be ideal.
>> 3. alternatives: approaching, movingTowards, advancedTowards.  Included in
>> the latest
>> revision of the proposal.
>> 
>> My big issues are "this thing says it goes through and it doesn't, this
>> thing says it goes to and it doesn't".
>> So long as those are fixed reasonably well, I am happy, even without the
>> naming being perfect.
>> 
>> I must misunderstand what it is you tweaked. You still write that the
>> other proposal doesn't remove the need for manual epsilon adjustment?
>> 
>> 
>> In order to separate this into two proposals, I had to make sure they
>> weren't depending on each other.
>> So this proposal *only* addresses the semantic mismatch I described 4 lines
>> up.
>> 
>> Manual epsilon adjustment is simply a floating point thing, and is discussed
>> at length in the
>> other proposal (Again, keep refreshing gist.github because both are works in
>> progress.)
>> 
>> [first...last] subsumes [from...through]. You might call this a..>b
>> 
>> 
>> I understand that you believe this makes the behavior of "through"
>> more sensible. I could even agree. But do we need this third stride
>> style, whatever it's called? Essentially, my question is: besides the
>> issue of epsilon adjustments, when have you encountered a case in your
>> code where you've needed to stride beyond the end point?
>> 
>> 
>> First, I renamed it with the two options a...>b, a..>=b and a..=>b to
>> suggest "reach or greater".
>> 
>> Second, yes, and I added a big new section on canonical use cases.
>> 
>> -- E
>>