[swift-evolution] [Proposal] Conventionalizing stride semantics

[Xiaodi Wu]

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
>