[swift-evolution] Feature proposal: Range operator with step

[Dave Abrahams]

on Tue Apr 05 2016, Erica Sadun <erica-AT-ericasadun.com> wrote:

>     On Apr 5, 2016, at 5:22 PM, Dave Abrahams via swift-evolution
>     <swift-evolution at swift.org> wrote:
>     I don't think that's obvious at all, because 0 ≮ 10
>
> Points brought up elsewhere:

Sorry, I've tried, but I'm afraid I don't understand any of this:

> * A range does not have direction, it is is an area of variation between lower
> and upper limits.

I don't know what you mean by “does not have direction.”  We're talking
about a concept whose Bound must be Comparable, so there's an implied
ordering of bounds: the lower bound precedes (or is coincident with) the
upper bound.  This ordering is also strongly implied by the form of the
..< operator.

> * A range does not go from a larger amount to a smaller amount because it is not
>   a sequence

Ranges with Integer strides *are* sequences.  Are you saying that
there's no good reason to expect any particular traversal order?

> 
> * Much of this problem goes away with striding (as Dave pointed out
> several times, sorry Dave)

What problem goes away with striding, and how?  I pointed this out?

> After consideration, I have been persuaded to the opinion that
>
>     stride(from: 0, to: -10, by: -1)
>
> and 
>
>     (-9...0).reverse()
>
> both represent the numbers -9, -8,...,0 better than any alternatives I
> have offered. I still prefer the stride version for intent and
> clarity.

I agree it's clearer.  The only question I have about this is whether
it's worth the complexity, since the choice isn't between the first and
the second, but between *both* and the second.

> That said, I also prefer my revised SE-0051 semantics for better
> representing what strides will attempt to do.


My biggest problem with that proposal is that it isn't clear that these
three distinctions map onto important use-cases.  The only reason we
ended up with stride(to:...) and stride(through:...) in the first place
was that we have closed and open ranges.  In other words, the two
original distinctions were not driven by use-cases.  Now SE-0051 is
talking about expanding them to three distinctions in the name of
clarity, still without use-cases to motivate them.  I'd rather roll
these features back while we still can, as long as there's another
reasonable way to express them, until we find out what kinds of things
people actually want to write that are difficult to express.

For example, there are all kinds of other ways to slice this:

    stride(over: 0..<200, by: -2)

    stride(100, stepsOver: 0..<200)

    (0..<200).divided(into: 100)
    
    (0..<200).stepping(100).times

    (0..<200) / 100

I'm not suggesting any of these, in particular.  I'm just saying, we
don't really even have a good idea of what will suit peoples' real-world
needs.

-- 
Dave