<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, May 20, 2016 at 5:40 PM, Tim Vermeulen <span dir="ltr">&lt;<a href="mailto:tvermeulen@me.com" target="_blank">tvermeulen@me.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div style="word-wrap:break-word"><span class=""><div><blockquote type="cite"><div dir="ltr"><div><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&#39;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&#39;s stride semantics that must change)</div><div>* 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><br></div></span><span class=""><div>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><br></div></span><div>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><span class=""><div><br></div><div><blockquote type="cite"><div dir="ltr"><div><div>* that stride(by:), or rather striding(by:), was too verbose</div></div></div></blockquote><br></div></span><span class=""><div>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></span></div></div></blockquote><div><br></div><div>Not all of these bullet points I&#39;ve summarized above were points of view that I personally espouse :)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div style="word-wrap:break-word"><span class=""></span><div><blockquote type="cite"><span class=""><div>On 21 May 2016, at 00:07, Xiaodi Wu &lt;<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>&gt; wrote:</div><br></span><div><div class="h5"><div><div dir="ltr">We&#39;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><br></div><div>The gist of the previous discussion centered on a few objections:</div><div><div>* that stride(by:), or rather striding(by:), was too verbose</div><div>* 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>* 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&#39;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&#39;s stride semantics that must change)</div><div>* 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></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 20, 2016 at 4:19 PM, Tim Vermeulen via swift-evolution <span dir="ltr">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;</span> wrote:<br><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><br>stride(from: 0, to: 10, by: 3)<br><br>to<br><br>(0..&lt;10).stride(by: 3)<br><br>and similarly, we can change<br><br>stride(from: 0, through: 10, by: 3)<br><br>to<br><br>(0…10).stride(by: 3)<br><br>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><br>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>_______________________________________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a></blockquote></div></div></div></div></div></div></div></blockquote></div></div></div></blockquote></div><br></div></div>