> For example, there are all kinds of other ways to slice this: > > stride(over: 0..<200, by: -2)
This seems like a particularly good solution. The way I understand it at least, it would allow ranges to always be ordered, with the only difference being whether it went start-to-end or end-to-start, determined by the stride's sign. It would also avoid the need for additional range operators. The main reason you would need `>..` is so you could say `array.endIndex>..array.startIndex`, but by using the sign to decide which direction to stride over the range, you instead stride over `array.startIndex..<array.endIndex`, which is exactly what we already have. Unfortunately, moving away from `stride(from:to/through:by:)` would kind of mess up an idea I've been developing for providing an "induction sequence" to replace the more complicated C-style for use cases, but I suppose that's the way it goes... (Link to that: https://gist.github.com/brentdax/b24dd89a770d9fe376984498d3185187) -- Brent Royal-Gordon Architechies _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
