Sure, I could give it a shot this weekend. On Wed, Mar 30, 2016 at 12:03 PM Erica Sadun <[email protected]> wrote:
> > 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]> > wrote: > > > on Tue Mar 29 2016, Xiaodi Wu <xiaodi.wu-AT-gmail.com > <http://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
