Ah, I think the conceptual muddle arises in the plan then. Specifically, I'd argue that not all Ranges with Strideable bounds should conform to Collection.
Conceptually, whether a type can be advanced by some distance (guaranteed by Strideable) is orthogonal to whether a type has an obviously correct increment when calling next() on its iterator. Thus, although *strides* with Strideable bounds should obviously conform to Collection, Ranges that conform to Collection should be constrained to types which imply that the Range represents a countable set (as the mathematicians say) of numbers. This distinction may come in handy for implementing strides that don't accumulate error. Striding through a Range that represents a countable set of elements shouldn't accumulate error and we can use what we already have--i.e. increment the current value every iteration without inspecting the value of the starting bound. Striding through a Range that represents an uncountable set of elements definitely requires reckoning from the starting bound every iteration. On Fri, Mar 25, 2016 at 11:25 AM Dave Abrahams via swift-evolution < [email protected]> wrote: > > on Thu Mar 24 2016, Xiaodi Wu <[email protected]> wrote: > > > On Thu, Mar 24, 2016 at 4:18 PM, Dave Abrahams via swift-evolution > > <[email protected]> wrote: > >> > >> on Wed Mar 23 2016, Xiaodi Wu <[email protected]> wrote: > >> > >>> So, in other words, you'd be satisfied with the following addition to > >>> the standard library? > > > >>> > >>> ``` > >>> extension Range where Element: Strideable { > >>> func by(step: Element.Stride) -> StrideTo<Element> { > >>> return startIndex.stride(to: endIndex, by: step) > >>> } > >>> } > >>> > >>> /* > >>> example of usage: > >>> > >>> for i in (1..<10).by(2) { > >>> print(i) > >>> } > >>> */ > >>> ``` > >> > >> > >> My current thinking is that: > >> > >> * `for x in 0.0..<3.0 {}` should probably be an error, because 1.0 is > >> not the obviously-right stride to use for non-integral numbers. That > >> would imply that floating types should not conform to Strideable, > >> which raises the question of whether Strideable should be folded into > >> the Integer protocol. > > > > Well, maybe I'm missing something, but `for x in 0.0..<3.0 { }` > > doesn't work as it is, and it doesn't seem to have anything to do with > > Strideable. Rather, HalfOpenInterval<Double> doesn't conform to > > SequenceType. > > True, but the plan is that: > > * Interval is going away > * Range will only require that its Bound be Comparable > * Ranges with Strideable bounds will conform to Collection > > (see the swift-3-indexing-model branch on GitHub) > > > I agree that `for x in 0.0..<3.0 { }` should continue not working, but > > maybe let's keep floating point types conforming to Strideable :) > > Those two things are not compatible with the plan we're going to > propose, as described above. > > >> > >> * `for x in (0.0..<20.0).striding(by: 1.3) {}` should work without > >> accumulating error > >> > > > > +1. > > > >> * `for x in 0..<3 {}` should work (obviously; that's the status quo) > >> > >> * `for x in (0..<20).striding(by: 2)` should work > >> > >> I think this might also handle the concerns that > >> > https://github.com/apple/swift-evolution/blob/master/proposals/0051-stride-semantics.md > >> was trying to address. > >> > >> If I thought extreme concision was important for this application, I'd > be > >> proposing something like > >> > >> for x in 0.0..<20.0//1.3 {} > >> > >> but personally, I don't, which is why I propose `.striding(by: x)` > >> rather than simply `.by(x)`, the latter being more open to > >> misinterpretation. > > > > Yeah, `.striding(by: x)` is pretty good. > > > >> > >> -- > >> 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 > > -- > 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
