# Add a stride(by:) method to ClosedRange

**URL:** <https://forums.swift.org/t/add-a-stride-by-method-to-closedrange/2714>\
**Category:** Discussion\
**Created:** [May 20, 2016, 9:19pm UTC](https://forums.swift.org/t/add-a-stride-by-method-to-closedrange/2714 "2016-05-20T21:19:36Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![timv](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/timv/32/13304_2.png) [@timv](https://forums.swift.org/u/timv)\
**Post date:** [May 20, 2016, 9:19pm UTC](https://forums.swift.org/t/add-a-stride-by-method-to-closedrange/2714/1 "2016-05-20T21:19:36Z")

</div>

If ClosedRange (Range in Swift 2.2.1) has a stride(by:) method, we can change

stride(from: 0, to: 10, by: 3)

to

(0..\<10).stride(by: 3)

and similarly, we can change

stride(from: 0, through: 10, by: 3)

to

(0…10).stride(by: 3)

As we can see, this syntax can replace both stride(from:to:by:) and stride(from:through:by:), and in my opinion it is more in line with the rest of Swift 3, similar to how Range.init(start:end:) will be deprecated in Swift 3 in favor of the … and ..\< operators.

I’m not sure if this proposed stride(by:) method could replace all uses of stride(from:to:by:) and stride(from:through:by:), but I think that at the very least it would be a nice addition to the standard library.

---

<div class="post-metadata">

**Author:** ![xwu](https://avatars.discourse-cdn.com/v4/letter/x/b487fb/32.png) [@xwu](https://forums.swift.org/u/xwu)\
**Post date:** [May 20, 2016, 10:07pm UTC](https://forums.swift.org/t/add-a-stride-by-method-to-closedrange/2714/2 "2016-05-20T22:07:43Z")

</div>

We've had this discussion on a few occasions. Unfortunately, copying links  
at the moment is a little tough, but I hope to do so at a later time (or  
others can jump in here).

The gist of the previous discussion centered on a few objections:  
\* that stride(by:), or rather striding(by:), was too verbose  
\* that both stride(from:to:by:) and Range.striding(by:) should not  
co-exist, so one would have to be removed in favor of the other  
\* that there was no one obvious behavior with a negative stride size (range  
operators require a smaller number on the lhs and a bigger one on the rhs,  
so you can't write `9...0`, but stride(from:to:by) can start from a bigger  
number to a smaller one, so there is a difference here that went through a  
lot of bikeshedding; there were several important people that made it clear  
that Range would not be modified for this use case, so it's stride  
semantics that must change)  
\* that for floating point ranges, removing stride(from:to:by:) in favor of  
striding(by:) would eliminate the possibility of expressing certain strides  
with open lower bound and negative stride size, partially motivating new  
range operators that are a whole nother issue

> **···**
>
> On Fri, May 20, 2016 at 4:19 PM, Tim Vermeulen via swift-evolution \< swift-evolution@swift.org\> wrote:
> 
> > If ClosedRange (Range in Swift 2.2.1) has a stride(by:) method, we can  
> > change
> > 
> > stride(from: 0, to: 10, by: 3)
> > 
> > to
> > 
> > (0..\<10).stride(by: 3)
> > 
> > and similarly, we can change
> > 
> > stride(from: 0, through: 10, by: 3)
> > 
> > to
> > 
> > (0…10).stride(by: 3)
> > 
> > As we can see, this syntax can replace both stride(from:to:by:) and  
> > stride(from:through:by:), and in my opinion it is more in line with the  
> > rest of Swift 3, similar to how Range.init(start:end:) will be deprecated  
> > in Swift 3 in favor of the … and ..\< operators.
> > 
> > I’m not sure if this proposed stride(by:) method could replace all uses of  
> > stride(from:to:by:) and stride(from:through:by:), but I think that at the  
> > very least it would be a nice addition to the standard library.  
> > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > swift-evolution mailing list  
> > swift-evolution@swift.org  
> > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)

---

<div class="post-metadata">

**Author:** ![timv](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/timv/32/13304_2.png) [@timv](https://forums.swift.org/u/timv)\
**Post date:** [May 20, 2016, 10:40pm UTC](https://forums.swift.org/t/add-a-stride-by-method-to-closedrange/2714/3 "2016-05-20T22:40:08Z")

</div>

> \* that there was no one obvious behavior with a negative stride size (range operators require a smaller number on the lhs and a bigger one on the rhs, so you can't write `9...0`, but stride(from:to:by) can start from a bigger number to a smaller one, so there is a difference here that went through a lot of bikeshedding; there were several important people that made it clear that Range would not be modified for this use case, so it's stride semantics that must change)  
> \* that for floating point ranges, removing stride(from:to:by:) in favor of striding(by:) would eliminate the possibility of expressing certain strides with open lower bound and negative stride size, partially motivating new range operators that are a whole nother issue

These are all great reasons why stride(from:to:by:) shouldn’t be removed, that I had not thought of. But isn’t this a good reason to let both function co-exist?

For example: (0..\<10).striding(by: 3) and stride(from: 0, to: 10, by: 3) look quite similar. However, in case we already have a range variable, someRange.striding(by: 3) is obviously a lot more readable than stride(from: someRange.startIndex, to: someRange.endIndex, by: 3). The reason I’m giving this example is that the two functions can have quite different use cases, so I’m unsure why one of them must be removed in favor of the other.

> \* that stride(by:), or rather striding(by:), was too verbose

striding(by:) doesn’t have the from, to, though parameter labels that the Swift 3 stride functions have, so to me this new method seems less verbose than the others. Maybe it depends on how you look at it. “to” and “through” basically refer to the “.” and “\<“ tails of the “…” and “..\<“ operators respectively, so that’s mainly why I think striding(by:) would be a cleaner and more intuitive way to stride through a sequence.

> **···**
>
> > On 21 May 2016, at 00:07, Xiaodi Wu \<xiaodi.wu@gmail.com \<mailto:xiaodi.wu@gmail.com\>\> wrote:
> > 
> > We've had this discussion on a few occasions. Unfortunately, copying links at the moment is a little tough, but I hope to do so at a later time (or others can jump in here).
> > 
> > The gist of the previous discussion centered on a few objections:  
> > \* that stride(by:), or rather striding(by:), was too verbose  
> > \* that both stride(from:to:by:) and Range.striding(by:) should not co-exist, so one would have to be removed in favor of the other  
> > \* that there was no one obvious behavior with a negative stride size (range operators require a smaller number on the lhs and a bigger one on the rhs, so you can't write `9...0`, but stride(from:to:by) can start from a bigger number to a smaller one, so there is a difference here that went through a lot of bikeshedding; there were several important people that made it clear that Range would not be modified for this use case, so it's stride semantics that must change)  
> > \* that for floating point ranges, removing stride(from:to:by:) in favor of striding(by:) would eliminate the possibility of expressing certain strides with open lower bound and negative stride size, partially motivating new range operators that are a whole nother issue
> > 
> > On Fri, May 20, 2016 at 4:19 PM, Tim Vermeulen via swift-evolution \<swift-evolution@swift.org \<mailto:swift-evolution@swift.org\>\> wrote:  
> > If ClosedRange (Range in Swift 2.2.1) has a stride(by:) method, we can change
> > 
> > stride(from: 0, to: 10, by: 3)
> > 
> > to
> > 
> > (0..\<10).stride(by: 3)
> > 
> > and similarly, we can change
> > 
> > stride(from: 0, through: 10, by: 3)
> > 
> > to
> > 
> > (0…10).stride(by: 3)
> > 
> > As we can see, this syntax can replace both stride(from:to:by:) and stride(from:through:by:), and in my opinion it is more in line with the rest of Swift 3, similar to how Range.init(start:end:) will be deprecated in Swift 3 in favor of the … and ..\< operators.
> > 
> > I’m not sure if this proposed stride(by:) method could replace all uses of stride(from:to:by:) and stride(from:through:by:), but I think that at the very least it would be a nice addition to the standard library.  
> > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > swift-evolution mailing list  
> > swift-evolution@swift.org \<mailto:swift-evolution@swift.org\>  
> > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)

---

<div class="post-metadata">

**Author:** ![xwu](https://avatars.discourse-cdn.com/v4/letter/x/b487fb/32.png) [@xwu](https://forums.swift.org/u/xwu)\
**Post date:** [May 20, 2016, 10:41pm UTC](https://forums.swift.org/t/add-a-stride-by-method-to-closedrange/2714/4 "2016-05-20T22:41:12Z")

</div>

> \* that there was no one obvious behavior with a negative stride size  
> (range operators require a smaller number on the lhs and a bigger one on  
> the rhs, so you can't write `9...0`, but stride(from:to:by) can start from  
> a bigger number to a smaller one, so there is a difference here that went  
> through a lot of bikeshedding; there were several important people that  
> made it clear that Range would not be modified for this use case, so it's  
> stride semantics that must change)  
> \* that for floating point ranges, removing stride(from:to:by:) in favor of  
> striding(by:) would eliminate the possibility of expressing certain strides  
> with open lower bound and negative stride size, partially motivating new  
> range operators that are a whole nother issue
> 
> These are all great reasons why stride(from:to:by:) shouldn’t be removed,  
> that I had not thought of. But isn’t this a good reason to let both  
> function co-exist?
> 
> For example: (0..\<10).striding(by: 3) and stride(from: 0, to: 10, by: 3)  
> look quite similar. However, in case we already have a range variable,  
> someRange.striding(by: 3) is obviously a lot more readable than  
> stride(from: someRange.startIndex, to: someRange.endIndex, by: 3). The  
> reason I’m giving this example is that the two functions can have quite  
> different use cases, so I’m unsure why one of them must be removed in favor  
> of the other.
> 
> \* that stride(by:), or rather striding(by:), was too verbose
> 
> striding(by:) doesn’t have the from, to, though parameter labels that the  
> Swift 3 stride functions have, so to me this new method seems less verbose  
> than the others. Maybe it depends on how you look at it. “to” and “through”  
> basically refer to the “.” and “\<“ tails of the “…” and “..\<“ operators  
> respectively, so that’s mainly why I think striding(by:) would be a cleaner  
> and more intuitive way to stride through a sequence.

Not all of these bullet points I've summarized above were points of view  
that I personally espouse :)

> **···**
>
> On Fri, May 20, 2016 at 5:40 PM, Tim Vermeulen \<tvermeulen@me.com\> wrote:
> 
> > On 21 May 2016, at 00:07, Xiaodi Wu \<xiaodi.wu@gmail.com\> wrote:
> > 
> > We've had this discussion on a few occasions. Unfortunately, copying links  
> > at the moment is a little tough, but I hope to do so at a later time (or  
> > others can jump in here).
> > 
> > The gist of the previous discussion centered on a few objections:  
> > \* that stride(by:), or rather striding(by:), was too verbose  
> > \* that both stride(from:to:by:) and Range.striding(by:) should not  
> > co-exist, so one would have to be removed in favor of the other  
> > \* that there was no one obvious behavior with a negative stride size  
> > (range operators require a smaller number on the lhs and a bigger one on  
> > the rhs, so you can't write `9...0`, but stride(from:to:by) can start from  
> > a bigger number to a smaller one, so there is a difference here that went  
> > through a lot of bikeshedding; there were several important people that  
> > made it clear that Range would not be modified for this use case, so it's  
> > stride semantics that must change)  
> > \* that for floating point ranges, removing stride(from:to:by:) in favor of  
> > striding(by:) would eliminate the possibility of expressing certain strides  
> > with open lower bound and negative stride size, partially motivating new  
> > range operators that are a whole nother issue
> > 
> > On Fri, May 20, 2016 at 4:19 PM, Tim Vermeulen via swift-evolution \< \> swift-evolution@swift.org\> wrote:
> > 
> > > If ClosedRange (Range in Swift 2.2.1) has a stride(by:) method, we can  
> > > change
> > > 
> > > stride(from: 0, to: 10, by: 3)
> > > 
> > > to
> > > 
> > > (0..\<10).stride(by: 3)
> > > 
> > > and similarly, we can change
> > > 
> > > stride(from: 0, through: 10, by: 3)
> > > 
> > > to
> > > 
> > > (0…10).stride(by: 3)
> > > 
> > > As we can see, this syntax can replace both stride(from:to:by:) and  
> > > stride(from:through:by:), and in my opinion it is more in line with the  
> > > rest of Swift 3, similar to how Range.init(start:end:) will be deprecated  
> > > in Swift 3 in favor of the … and ..\< operators.
> > > 
> > > I’m not sure if this proposed stride(by:) method could replace all uses  
> > > of stride(from:to:by:) and stride(from:through:by:), but I think that at  
> > > the very least it would be a nice addition to the standard library.  
> > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > > swift-evolution mailing list  
> > > swift-evolution@swift.org  
> > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)

---

<div class="post-metadata">

**Author:** ![dabrahams](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/dabrahams/32/9815_2.png) [@dabrahams](https://forums.swift.org/u/dabrahams)\
**Post date:** [May 26, 2016, 5:09pm UTC](https://forums.swift.org/t/add-a-stride-by-method-to-closedrange/2714/5 "2016-05-26T17:09:08Z")

</div>

> &nbsp;&nbsp;&nbsp;&nbsp;\* that there was no one obvious behavior with a negative stride size (range  
> &nbsp;&nbsp;&nbsp;&nbsp;operators require a smaller number on the lhs and a bigger one on the rhs,  
> &nbsp;&nbsp;&nbsp;&nbsp;so you can't write `9...0`, but stride(from:to:by) can start from a bigger  
> &nbsp;&nbsp;&nbsp;&nbsp;number to a smaller one, so there is a difference here that went through a  
> &nbsp;&nbsp;&nbsp;&nbsp;lot of bikeshedding; there were several important people that made it clear  
> &nbsp;&nbsp;&nbsp;&nbsp;that Range would not be modified for this use case, so it's stride semantics  
> &nbsp;&nbsp;&nbsp;&nbsp;that must change)  
> &nbsp;&nbsp;&nbsp;&nbsp;\* that for floating point ranges, removing stride(from:to:by:) in favor of  
> &nbsp;&nbsp;&nbsp;&nbsp;striding(by:) would eliminate the possibility of expressing certain strides  
> &nbsp;&nbsp;&nbsp;&nbsp;with open lower bound and negative stride size, partially motivating new  
> &nbsp;&nbsp;&nbsp;&nbsp;range operators that are a whole nother issue
> 
> These are all great reasons why stride(from:to:by:) shouldn’t be removed, that I  
> had not thought of. But isn’t this a good reason to let both function co-exist?

I am very fond of the idea of getting rid of the somewhat ugly and  
potentially misinterpretable to:/through: labels by using the semantics  
already embedded in ranges (in fact, I proposed it originally).  
However, I appreciate the reasons we might need the other forms and am  
wary of creating a design with duplicated functionality that doesn't  
appear to have coherence. My conclusion is that we don't quite yet know  
what the right design is.

> For example: (0..\<10).striding(by: 3) and stride(from: 0, to: 10, by: 3) look  
> quite similar. However, in case we already have a range variable,  
> someRange.striding(by: 3) is obviously a lot more readable than stride(from:  
> someRange.startIndex, to: someRange.endIndex, by: 3). The reason I’m giving this  
> example is that the two functions can have quite different use cases, so I’m  
> unsure why one of them must be removed in favor of the other.

We don't normally add duplicated functionality as syntactic sugar unless  
the use case for it is \*extremely\* common and compelling. I'm not sure  
this rises to that level. If stride(from:to:by:) is more general than  
Range.striding(by:), I am hard pressed to justify adding the latter  
form, as much as I love it.

> **···**
>
> on Fri May 20 2016, Tim Vermeulen \<swift-evolution@swift.org\> wrote:
> 
> > &nbsp;&nbsp;&nbsp;&nbsp;\* that stride(by:), or rather striding(by:), was too verbose
> > 
> > striding(by:) doesn’t have the from, to, though parameter labels that the Swift  
> > 3 stride functions have, so to me this new method seems less verbose than the  
> > others. Maybe it depends on how you look at it. “to” and “through” basically  
> > refer to the “.” and “\<“ tails of the “…” and “..\<“ operators respectively, so  
> > that’s mainly why I think striding(by:) would be a cleaner and more intuitive  
> > way to stride through a sequence.
> > 
> > &nbsp;&nbsp;&nbsp;&nbsp;On 21 May 2016, at 00:07, Xiaodi Wu \> \<xiaodi.wu@gmail.com\> wrote:
> > 
> > &nbsp;&nbsp;&nbsp;&nbsp;We've had this discussion on a few occasions. Unfortunately, copying links  
> > &nbsp;&nbsp;&nbsp;&nbsp;at the moment is a little tough, but I hope to do so at a later time (or  
> > &nbsp;&nbsp;&nbsp;&nbsp;others can jump in here).
> > 
> > &nbsp;&nbsp;&nbsp;&nbsp;The gist of the previous discussion centered on a few objections:
> > 
> > &nbsp;&nbsp;&nbsp;&nbsp;\* that stride(by:), or rather striding(by:), was too verbose  
> > &nbsp;&nbsp;&nbsp;&nbsp;\* that both stride(from:to:by:) and Range.striding(by:) should not co-exist,  
> > &nbsp;&nbsp;&nbsp;&nbsp;so one would have to be removed in favor of the other  
> > &nbsp;&nbsp;&nbsp;&nbsp;\* that there was no one obvious behavior with a negative stride size (range  
> > &nbsp;&nbsp;&nbsp;&nbsp;operators require a smaller number on the lhs and a bigger one on the rhs,  
> > &nbsp;&nbsp;&nbsp;&nbsp;so you can't write `9...0`, but stride(from:to:by) can start from a bigger  
> > &nbsp;&nbsp;&nbsp;&nbsp;number to a smaller one, so there is a difference here that went through a  
> > &nbsp;&nbsp;&nbsp;&nbsp;lot of bikeshedding; there were several important people that made it clear  
> > &nbsp;&nbsp;&nbsp;&nbsp;that Range would not be modified for this use case, so it's stride semantics  
> > &nbsp;&nbsp;&nbsp;&nbsp;that must change)  
> > &nbsp;&nbsp;&nbsp;&nbsp;\* that for floating point ranges, removing stride(from:to:by:) in favor of  
> > &nbsp;&nbsp;&nbsp;&nbsp;striding(by:) would eliminate the possibility of expressing certain strides  
> > &nbsp;&nbsp;&nbsp;&nbsp;with open lower bound and negative stride size, partially motivating new  
> > &nbsp;&nbsp;&nbsp;&nbsp;range operators that are a whole nother issue
> > 
> > &nbsp;&nbsp;&nbsp;&nbsp;On Fri, May 20, 2016 at 4:19 PM, Tim Vermeulen via swift-evolution \> \<swift-evolution@swift.org\> wrote:
> > 
> > &nbsp;&nbsp;&nbsp;&nbsp;If ClosedRange (Range in Swift 2.2.1) has a stride(by:) method, we can  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;change
> > 
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;stride(from: 0, to: 10, by: 3)
> > 
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;to
> > 
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(0..\<10).stride(by: 3)
> > 
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;and similarly, we can change
> > 
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;stride(from: 0, through: 10, by: 3)
> > 
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;to
> > 
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(0…10).stride(by: 3)
> > 
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;As we can see, this syntax can replace both stride(from:to:by:) and  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;stride(from:through:by:), and in my opinion it is more in line with the  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;rest of Swift 3, similar to how Range.init(start:end:) will be  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;deprecated in Swift 3 in favor of the … and ..\< operators.
> > 
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;I’m not sure if this proposed stride(by:) method could replace all uses  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;of stride(from:to:by:) and stride(from:through:by:), but I think that at  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;the very least it would be a nice addition to the standard library.  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;swift-evolution mailing list  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;swift-evolution@swift.org  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)
> > 
> > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > swift-evolution mailing list  
> > swift-evolution@swift.org  
> > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)
> 
> --  
> Dave