> On Mar 29, 2016, at 11:26 PM, Xiaodi Wu via swift-evolution > <[email protected]> wrote: > > On Tue, Mar 29, 2016 at 7:48 PM, Dave Abrahams <[email protected] > <mailto:[email protected]>> wrote: >> >> on Tue Mar 29 2016, Xiaodi Wu <xiaodi.wu-AT-gmail.com> wrote: >> >>> Relatedly, while you're tackling this big revision: >>> >>> I've tried to play around with what it would take to write a generic >>> non-error-accumulating striding method, and afaict, it would be >>> enormously cleaner if Strideable types are guaranteed to have + and * >>> (well, Strideable.Stride needs *, to be more accurate), >> >> That should happen automatically, since it conforms to SignedNumber, >> when we get the Integer protocols updated (project currently on hold while >> we land this other revision). >> >>> since the iterator needs to be able to compute end = start + iteration >>> * stride. >> >> Don't you need division too if you're going to do this? > > I didn't seem to ever need division. See attached playground (which > borrows shamelessly from existing code and Erica's proposal, and which > is written in Swift 2.2 because that's what I had handy).
Have you considered trying to extend the `swift-3-indexing-model <https://github.com/apple/swift/tree/swift-3-indexing-model>` branch at the Swift repo to take the floating point approach into account? Dave A is working on a massive overhaul of ranges (including `Countable` items and one would presume floating point closed and open intervals as well), and I'd love to see better implementations of, for example, `(x..<y).striding(by:z)` happen for Double types. I'd be happy to throw a proposal together based on a proof of concept, if you had the flexibility to work on the coding. -- Erica
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
