[swift-evolution] [Draft]: Introducing a striding(by:) method on 3.0 ranges

[Xiaodi Wu]

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 at swift.org> wrote:

>
> on Mon Apr 11 2016, Dave Abrahams <swift-evolution at 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160425/e8b81c33/attachment.html>