[swift-evolution] [Draft]: Introducing a striding(by:) method on 3.0 ranges

[Brent Royal-Gordon]

> We propose to introduce a striding(by:) method on the revised 3.0 Range type.

I take it that we're taking an incremental approach here, and further steps like:

* Adding new range operators
* Making all collections Strideable
* Unifying Range and IntervalType so we can stride over non-integers again
* Correctly striding over floats

Are out of scope for this particular proposal.

> (0 ... 9).striding(by: 2) == [0, 2, 4, 6, 8]
> (0 ..< 9).striding(by: 2) == [0, 2, 4, 6, 8]
> (0 <.. 9).striding(by: 2) ==    [2, 4, 6, 8]
> (0 <.< 9).striding(by: 2) ==    [2, 4, 6, 8]

I favor `stride(over: 0...9, by: 2)`—or perhaps even `Stride(over: 0...9, by: 2)`, where `Stride` is a replacement for `StrideTo` and `StrideThrough`—over a `striding(by:)` method.  The precedence of the range-construction operators makes calling methods on a Range unusually difficult and ugly. (And I don't think adjusting the precedence is a realistic option; that would break things like `0..<array.count`.) Passing the Range as a parameter instead evades this issue.

> To reverse a stride, call reverse() on the results:
> 
> (0 ... 9).striding(by: 2).reverse() == [8, 6, 4, 2, 0]

Does this have different behavior from `(0...9).striding(by: -2)`? (I know it probably has a different implementation.)

-- 
Brent Royal-Gordon
Architechies