[swift-evolution] Feature proposal: Range operator with step

[Howard Lovatt]

I like the idea that Array gains `strinding(by:)` but would also like Range
to be like an array, same interface, and hence also gain `strinding(by:)`,
hence:

calendar[(startDate ..< endDate).striding(by: .Day)]


  -- Howard.

On 7 April 2016 at 10:53, Dave Abrahams via swift-evolution <
swift-evolution at swift.org> wrote:

>
> on Wed Apr 06 2016, Brent Royal-Gordon <brent-AT-architechies.com> wrote:
>
> >> I (am familiar with and) agree with Dijkstra's logic, but not with your
> >> conclusion about it.  The fact that one representation is more natural
> >> for most common computing tasks doesn't mean it's not worth supporting
> >> the other representations.
> >
> > I'm not saying that Dijkstra proves that we don't need any other range
> > operators. Rather, I'm saying that he demonstrates why supporting
> > `..<` but not `<..` is not arbitrary or capricious. Dijkstra's
> > argument *permits* us to privilege `..<` as uniquely important, but
> > doesn't *force* us to do so.
>
> I agree.  And I still think it's uniquely important ;-).
>
> > To another person just now, you said:
> >
> >> He was talking about ranges of integer indices, though, and even
> >> more-specifically about how to address arrays.  Range<Bound> is a more
> >> general concept that applies to much more than indices.  Once you
> >> involve floating point (and rationals, and patterns for matching,
> >> e.g. UnicodeScalar("a")..."z"), the conclusions no longer apply.
> >
> > I actually think he was talking a little more broadly than
> > that—essentially, he was discussing ordered, discrete types. In
> > principle, the same argument applies to UnicodeScalars,
>
> Yes, but I don't know if he had such types.
>
> > but not to floating-point numbers (unless you use treat floats as a
> > discrete type using `nextafter` as the `successor()` operation, which
> > is coherent but not very useful in practice). Having said that, I *do*
> > think that `...` is in practice quite useful for many types. I'm less
> > certain that `<..` or `<.<` are.
> >
> > * * *
> >
> > By the way, another reason to have `stride` as a free function is that
> > I think some types need a "strider", an instance which performs the
> > striding.
> >
> > That was the conclusion I came to when I started experimenting with
> > striding over NSDates a week or two ago. The best design I could come
> > up with looked like this:
> >
> >       calendar.using(.Day).stride(from: startDate, to: endDate, by: 1)
>
> > The `start` and `end` parameters could be grouped together into a
> > single parameter to match `stride(over:by:)`, but you can't put the
> > calendar or the unit into the stride—without them, there is no
> > coherent way to calculate the distance between two dates.
> >
> > So if some types need a strider, and will need to have the method
> > structured as `strider.stride(something:by:)`, it seems like the free
> > function version for types which *don't* need a strider ought to be
> > `stride(something:by:)`. The `something.striding(by:)` design can't be
> > easily adapted to this situation.
>
>   calendar[startDate..<endDate].striding(by: .Day)
>
> ?
>
> --
> 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/20160407/7eeb8f9c/attachment.html>