Yup, we're going to try to touch base, the authors of the current draft that is, sometime this week. More to come, hopefully.
On Mon, Apr 25, 2016 at 8:13 PM, Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: > > on Mon Apr 11 2016, Dave Abrahams <swift-evolution@swift.org> wrote: > > > on Sun Apr 10 2016, Michel Fortin <michel.fortin-AT-michelf.ca> wrote: > > > >> So if you take this into account, storing the comparator as part of > >> the stride makes the cost more predictable: not only there is one > >> branch less in `next()`, but you avoid evaluating the condition which > >> has an unknown cost: the `stride < 0` part. > >> > >> And ideally you should make sure the optimizer can replace the > >> indirect call with a direct call to the comparator. You do that by not > >> making the comparator choice dependent on a runtime value, hence why I > >> suggested having distinct "down" variants for the convenience > >> functions: `stride(from:downTo:by:)` and > >> `stride(from:downThrough:by:)` and `Range.strindingDown(by:)`. > > > > A few points: > > > > 1. There's a balance to be struck between making sure the optimizer can > > do a good job under *absolutely all circumstances*, and keeping the > > API surface area small and simple. That makes me somewhat reluctant > > to add “down” variants, if as I suspect the optimizer does well in > > the vast majority of cases without them. > > > > 2. Similarly, I view r.striding(by: x) as redundant with stride(from: x, > > to: y, by: z). I'd rather not have them both. > > > > 3. The fact that we're migrating C-style for loops to > > uses of stride, as noted in https://github.com/apple/swift/pull/2125, > > has convinced me that, sadly, we may need an answer that doesn't > > involve ranges. But maybe something like > > > > for x in loop(from: 0.1, while: { $0 < 10 }, next: { $0 + .2 }) > > > > is sufficient for this purpose. > > After some reflection, I don't really want to see a construct like #3 in > the standard library, and Chris has clarified for me that the standard > library doesn't need to solve the migration problems created by the > removal of C-style “for” loops. So, if I have inadvertently killed > progress on this proposal by bringing it up, please allow me to retract > item 3 above. > > I'd love to see the floating-point stride thing solved for Swift 3, but > the window for changes is getting narrower, so if the community wants to > move forward with the proposal (and implementation), that would be > awesome. > > Cheers, > > -- > Dave > > _______________________________________________ > 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
