> 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 _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
