> On Apr 6, 2016, at 17:00, Dave Abrahams via swift-evolution > <[email protected]> wrote: > > > on Wed Apr 06 2016, Erica Sadun <[email protected]> wrote: > >>> On Apr 6, 2016, at 2:17 PM, Xiaodi Wu <[email protected]> wrote: >>> 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. >> >> I wouldn't suggest doing so. I'm just saying that for a half-open interval, >> there is no max value >> so it makes no sense mathematically to have a first value and a >> negative step. > > I don't agree. It seems to me that striding downwards over a half-open > range r should always begin with r.upperBound - s (modulo any necessary > adjustments to avoid FP error), where -s is the stride amount. Why is > that mathematical nonsense? > This doesn't seem intuitive to me at all.
I can think of three interpretations of '(lBound..<uBound).striding(by:-step)': - start at max value in range that is less than 'uBound' - start at 'bound - step' (your suggestion) - start where-ever is needed to end exactly at lBound None of these interpretations seem intuitive to me. I agree with Erica that the start point when striding should be an inclusive bound. A negative stride should only work with a closed range (or '<..' if it is defined). > Another point to consider: striding is also a sensible operation over > collections, and some ranges are collections. The stride semantics must > coincide in those cases. I expect that constraint narrows down the > reasonable semantic choices considerably. > >> You're not so restricted with: >> >> * positive steps >> * closed intervals >> >> -- E >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution > > -- > Dave > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
