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 < [email protected]> 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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
