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

Dave Abrahams dabrahams at apple.com
Fri Mar 25 20:10:04 CDT 2016

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

> 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.


More information about the swift-evolution mailing list