[swift-evolution] Add a stride(by:) method to ClosedRange

[Xiaodi Wu]

On Fri, May 20, 2016 at 5:40 PM, Tim Vermeulen <tvermeulen at me.com> wrote:

> * 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 21 May 2016, at 00:07, Xiaodi Wu <xiaodi.wu at 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 at 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 at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160520/7f5e9794/attachment.html>