I think a lightbulb just went on for me:<br><br>You're talking about expressing something in the vein of `(0..<200).striding(by: -2)`, which has I'm sure many use cases, and which isn't straightforward to express with the current free function--I hadn't considered that.<br><br>Meanwhile, I was trying to talk about something like `stride(from: 200, to: 0, by: -2)`, which is easily expressed today but isn't straightforward at all to preserve with only ranges. Clearly, given that this is what's on offer currently, someone who designed the language thinks (or thought) it's of some use.<br><br>In the absence of information as to which is more in demand, couldn't we have both? If it must be a method on a range, then I would advocate for having what seems to be an utterly reasonable set of options for striding backwards:<br><br>```<br>(0...200).striding(by: -2) // [a, b]<br>(0..<200).striding(by: -2) // [a, b)<br>(0<..200).striding(by: -2) // (a, b]<br>```<br><div class="gmail_quote"><div dir="ltr">On Wed, Apr 6, 2016 at 12:10 PM Dave Abrahams via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
on Wed Apr 06 2016, Brent Royal-Gordon <brent-AT-architechies.com> wrote:<br>
<br>
>> For example, there are all kinds of other ways to slice this:<br>
>><br>
>> stride(over: 0..<200, by: -2)<br>
><br>
> This seems like a particularly good solution. The way I understand it<br>
> at least, it would allow ranges to always be ordered, with the only<br>
> difference being whether it went start-to-end or end-to-start,<br>
> determined by the stride's sign.<br>
<br>
This is no different in principle from<br>
<br>
(0..<200).striding(by: -2)<br>
<br>
Again, I wasn't trying to suggest any of the solutions listed there.<br>
The point I was making was that we don't have enough information to<br>
design more than<br>
<br>
(0..<200).striding(by: -2)<br>
<br>
> It would also avoid the need for additional range operators. The main<br>
> reason you would need `>..` is so you could say<br>
> `array.endIndex>..array.startIndex`, but by using the sign to decide<br>
> which direction to stride over the range, you instead stride over<br>
> `array.startIndex..<array.endIndex`, which is exactly what we already<br>
> have.<br>
><br>
> Unfortunately, moving away from `stride(from:to/through:by:)` would<br>
> kind of mess up an idea I've been developing for providing an<br>
> "induction sequence" to replace the more complicated C-style for use<br>
> cases, but I suppose that's the way it goes...<br>
><br>
> (Link to that: <a href="https://gist.github.com/brentdax/b24dd89a770d9fe376984498d3185187" rel="noreferrer" target="_blank">https://gist.github.com/brentdax/b24dd89a770d9fe376984498d3185187</a>)<br>
<br>
--<br>
Dave<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div>