on Tue Apr 05 2016, Erica Sadun <erica-AT-ericasadun.com> wrote: > On Apr 5, 2016, at 5:22 PM, Dave Abrahams via swift-evolution > <swift-evolution@swift.org> wrote: > I don't think that's obvious at all, because 0 ≮ 10 > > Points brought up elsewhere:
Sorry, I've tried, but I'm afraid I don't understand any of this: > * A range does not have direction, it is is an area of variation between lower > and upper limits. I don't know what you mean by “does not have direction.” We're talking about a concept whose Bound must be Comparable, so there's an implied ordering of bounds: the lower bound precedes (or is coincident with) the upper bound. This ordering is also strongly implied by the form of the ..< operator. > * A range does not go from a larger amount to a smaller amount because it is > not > a sequence Ranges with Integer strides *are* sequences. Are you saying that there's no good reason to expect any particular traversal order? > > * Much of this problem goes away with striding (as Dave pointed out > several times, sorry Dave) What problem goes away with striding, and how? I pointed this out? > After consideration, I have been persuaded to the opinion that > > stride(from: 0, to: -10, by: -1) > > and > > (-9...0).reverse() > > both represent the numbers -9, -8,...,0 better than any alternatives I > have offered. I still prefer the stride version for intent and > clarity. I agree it's clearer. The only question I have about this is whether it's worth the complexity, since the choice isn't between the first and the second, but between *both* and the second. > That said, I also prefer my revised SE-0051 semantics for better > representing what strides will attempt to do. My biggest problem with that proposal is that it isn't clear that these three distinctions map onto important use-cases. The only reason we ended up with stride(to:...) and stride(through:...) in the first place was that we have closed and open ranges. In other words, the two original distinctions were not driven by use-cases. Now SE-0051 is talking about expanding them to three distinctions in the name of clarity, still without use-cases to motivate them. I'd rather roll these features back while we still can, as long as there's another reasonable way to express them, until we find out what kinds of things people actually want to write that are difficult to express. For example, there are all kinds of other ways to slice this: stride(over: 0..<200, by: -2) stride(100, stepsOver: 0..<200) (0..<200).divided(into: 100) (0..<200).stepping(100).times (0..<200) / 100 I'm not suggesting any of these, in particular. I'm just saying, we don't really even have a good idea of what will suit peoples' real-world needs. -- Dave _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution