<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div dir="ltr" class=""><div class=""><div class="">* 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)</div><div class="">* 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</div></div></div></blockquote></div><div class=""><br class=""></div><div class="">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?</div><div class=""><br class=""></div><div class="">For example: (0..&lt;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.</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div dir="ltr" class=""><div class=""><div class="">* that stride(by:), or rather striding(by:), was too verbose</div></div></div></blockquote><br class=""></div><div class="">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 “&lt;“ tails of the “…” and “..&lt;“ operators respectively, so that’s mainly why I think striding(by:) would be a cleaner and more intuitive way to stride through a sequence.</div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On 21 May 2016, at 00:07, Xiaodi Wu &lt;<a href="mailto:xiaodi.wu@gmail.com" class="">xiaodi.wu@gmail.com</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">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).<div class=""><br class=""></div><div class="">The gist of the previous discussion centered on a few objections:</div><div class=""><div class="">* that stride(by:), or rather striding(by:), was too verbose</div><div class="">* 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</div><div class="">* 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)</div><div class="">* 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</div><div class="gmail_extra"><br class=""></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Fri, May 20, 2016 at 4:19 PM, Tim Vermeulen via swift-evolution&nbsp;<span dir="ltr" class="">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>&gt;</span>&nbsp;wrote:<br class=""><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;">If ClosedRange (Range in Swift 2.2.1) has a stride(by:) method, we can change<br class=""><br class="">stride(from: 0, to: 10, by: 3)<br class=""><br class="">to<br class=""><br class="">(0..&lt;10).stride(by: 3)<br class=""><br class="">and similarly, we can change<br class=""><br class="">stride(from: 0, through: 10, by: 3)<br class=""><br class="">to<br class=""><br class="">(0…10).stride(by: 3)<br class=""><br class="">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 ..&lt; operators.<br class=""><br class="">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.<br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></blockquote></div></div></div></div></div></blockquote></div></div></body></html>