On Wed, Apr 6, 2016 at 1:43 PM, Dave Abrahams <dabrah...@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@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. _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
