I think my opinion is largely the same. A range is not a stride, and sometimes we have use for striding backwards, a use case that shouldn't be penalized. +1 to the free function.
I wouldn't mind, orthogonally, a way to express (a, b] as a range. It just seems like that should be of use, somewhere. Finally, orthogonal to all of the above, I'm super eager to end error accumulation in floating point strides. On Tue, Apr 5, 2016 at 6:52 PM Erica Sadun via swift-evolution < swift-evolution@swift.org> 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: > > * A range does not have direction, it is is an area of variation between > lower and upper limits. > * A range does not go from a larger amount to a smaller amount because it > is not a sequence > * Much of this problem goes away with striding (as Dave pointed out > several times, sorry Dave) > > 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. > > That said, I also prefer my revised SE-0051 semantics for better > representing what strides will > attempt to do. > > -- Erica > p.s. Thanks all for the patient explanations > > > > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution