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

[Xiaodi Wu]

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/8672b0e8/attachment.html>