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

[Dave Abrahams]

on Fri May 20 2016, Tim Vermeulen <swift-evolution at swift.org> 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?

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.

>
>
>     * 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 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
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-- 
Dave