Good points! -Thorsten
> Am 25.03.2016 um 19:29 schrieb Xiaodi Wu via swift-evolution > <[email protected]>: > > 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
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
