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

[Xiaodi Wu]

On Wed, Apr 6, 2016 at 1:43 PM, Dave Abrahams <dabrahams at apple.com> wrote:
>
> on Wed Apr 06 2016, Erica Sadun <erica-AT-ericasadun.com> wrote:
>
>>     On Apr 6, 2016, at 12:16 PM, Dave Abrahams via swift-evolution
>>     <swift-evolution at swift.org> wrote:
>>     (0..<199).striding(by: -2)
>>
>>     are even or odd.
>>
>> (0..<199).striding(by: -2): 0..<199 == 0...198 Even
>> (1..<199).striding(by: -2): 1..<199 == 1...198 Even
>
> I understand the logic that got you there, but I find it incredibly
> counter-intuitive that striding by 2s over a range with odd endpoints
> should produce even numbers... I can't imagine any way I'd be convinced
> that was a good idea.
>
>> (0..<198).striding(by: -2): 1..<198 == 0...197 Odd
>> (1..<198).striding(by: -2): 1..<198 == 1...197 Odd
>>

One other aspect of the counterintuitiveness is that
`(a..<b).striding(by: -c)` has been discussed, even in this thread, as
essentially reversing the sequence given by `(a..<b).striding(by: c)`.
That would not be the case with the logic presented here. I worry that
there is no obviously correct interpretation of `(a..<b).striding(by:
-c)` and wonder if any conclusion arrived at would necessarily be more
confusing that `stride(from:to:by:)`.

Prohibiting StrideTo with floating-point ranges altogether would be
distressing. IMO, it's plenty distressing that backwards
floating-point StrideTo as it currently exists might go away.