on Fri Mar 25 2016, Xiaodi Wu <xiaodi.wu-AT-gmail.com> wrote: > 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.
I think any countable set should be OK, regardless of whether the elements are numbers. Ranges of UnsafePointers, for example, are countable. > 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. So, what does this Countable protocol look like? It seems like it would bring back the Index protocols that are otherwise obviated by this plan... not a jolly prospect. -- Dave _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
