Le 9 avr. 2016 à 13:23, Xiaodi Wu <xiaodi...@gmail.com> a écrit : > The sign of the stride size is already (in the current version of Swift) > evaluated in the stride generator/iterator; as written, it is evaluated every > time next() is called, but of course that is optimized away when possible.
You're right. I had to check the code before I could believe it. How terrible. There's two branches per loop iteration: https://github.com/apple/swift/blob/swift-2.2-branch/stdlib/public/core/Stride.swift#L136 I know the optimizer is probably going to be good enough to elide the first branch in most circumstances... but still, relying on the optimizer doing its magic does not seem very wise. It's not like you'll get a warning when that branch is not elided. > What we are proposing adds no additional logic to the loop. I can't see a > reason why inserting a line to trap on a negative stride size would show any > measurable improvement in performance compared to inserting a line to use > upperBound for start and lowerBound for end instead of vice versa when > initializing an instance of StrideTo/StrideThrough. That suggestion was based on consistency more than performance. The first part of my last email was *not* about performance. I was saying that semantically it would make more sense to me if it did the same thing as zero. "I think to be consistent it should trap, like with a step of zero, because you can't go from 0 to 9 with a negative step." I guess we can agree to disagree on this. Performance-wise, it would actually be one less branch at the start of the loop since you can fold it with the zero case using `predcondition(stride > 0)`. And I now realize that it'd make it possible to eliminate that dubious extra branch in `next()`, so that's one giant reason to do it. I guess my main issue with `stride` as it is today is that it tries to be clever in the edge cases instead of just giving you an infinite sequence. Reversing the start and stop boundaries when the step is negative is just a way of making it even more clever. So perhaps it fits with the current direction, but it does not suit me. -- Michel Fortin https://michelf.ca _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
