While I’m in favour of the basic idea I think the operator selection is too
complex, and I’m not sure about the need for negative strides. Really all I
want are the following:
(0 ... 6).striding(by: 2) // [0, 2, 4, 6] x from 0 to 6
(0 ..< 6).striding(by: 2) // [0, 2, 4] x from 0 while
<6
(6 ... 0).striding(by: 2) // [6, 4, 2, 0] x from 6 to 0
(6 ..> 0).striding(by: 2) // [6, 4, 2] x from 6 while
>0
Everything else should be coverable either by flipping the order, or using
.reverse(). The main advantage is that there’s only one new operator to clarify
the 6 ..> 0 case, though you could always just reuse the existing operator if
you just interpret it as “x from 6 to, but not including, 0"
I dunno, I just don’t think that introducing tons of new operators is going to
simplify things, and could lead to way more mistakes in practice; the only
mistake above would be putting the indices in the wrong order and accidentally
reversing the result.
Also, I’m against negative strides; while they could be useful for convenience
(avoid the need for .reverse or flipping values) I’m just not sure that it
makes sense. To me a stride is a distance, thus absolute, what matters is the
direction of the range. Naturally we’d need ranges with a direction, but with
collections requiring it to be in a particular order (or ignoring it and
flipping where necessary).
> On 8 Apr 2016, at 19:37, Erica Sadun via swift-evolution
> <[email protected]> wrote:
>
> Draft here: https://gist.github.com/erica/a51a981ee0352235204692affa959307
> <https://gist.github.com/erica/a51a981ee0352235204692affa959307> Feedback
> solicited, both positive and negative.
> We've also got a related proposal about expanding ranges, which you can look
> at here (https://gist.github.com/erica/af92c541a0fb69fce1b7aaf8374a5aa9
> <https://gist.github.com/erica/af92c541a0fb69fce1b7aaf8374a5aa9>)
> but we want to float this one first.
>
> Thanks, -- E
>
>
>
> Proposal: SE-XXXX
> <https://gist.github.com/erica/a51a981ee0352235204692affa959307/edit>
> Author(s): Xiaodi Wu <https://github.com/xwu>, Pyry Jahkola
> <http://github.com/pyrtsa>, Nate Cook <http://github.com/natecook1000>, Erica
> Sadun <http://github.com/erica>
> Status: TBD
> Review manager: TBD
>
> <https://gist.github.com/erica/a51a981ee0352235204692affa959307#introduction>Introduction
>
> We propose to introduce a striding(by:) method on the revised 3.0 Range type.
>
> This proposal was discussed on the Swift Evolution list in the Feature
> proposal: Range operator with step
> <http://search.gmane.org/search.php?group=gmane.comp.lang.swift.evolution&query=Feature+proposal%3A+Range+operator+with+step>
> thread. (Direct link
> <http://thread.gmane.org/gmane.comp.lang.swift.evolution/12801/focus=13051>
> to original thread)
>
>
> <https://gist.github.com/erica/a51a981ee0352235204692affa959307#motivation>Motivation
>
> Updating Range for Swift 3 offers a window of opportunity to simultaneously
> improve strides.
>
> Under current Swift 3 plans, n.stride(to:/through:, by:) will be replaced
> with a standalone stride(from:, to:/through:, by:) function. We propose to
> replace this change with a method on ranges. Using a method reduces overall
> API surface area compared to free functions.
>
> In its current incarnation, the standalone stride function uses confusing
> semantics. The current to implementation returns values in [start, end) and
> will never reach or get to end. The current through implementation returns
> values in [start, end]. It may never reach end and certainly never goes
> through that value. Our proposed method introduces simple, expected semantics
> that can be extended to both countable and continuous ranges, and to open and
> closed intervals (both half-open and fully-open).
>
>
> <https://gist.github.com/erica/a51a981ee0352235204692affa959307#detail-design>Detail
> Design
>
> The striding(by:) method is called on ranges. When used with a positive step
> size, the count starts from the lower bound. With a negative step size, the
> count starts from the upper bound. These bounds apply regardless of whether
> they are inclusive or exclusive.
>
> The following examples should cover all corner cases and include possible
> cases should Swift 3 introduce a full complement of open and closed ranges.
> The syntax for non-canonical range types is not fixed and can be discussed
> under separate cover.
>
> (0 ... 9).striding(by: 2) == [0, 2, 4, 6, 8]
> (0 ..< 9).striding(by: 2) == [0, 2, 4, 6, 8]
> (0 <.. 9).striding(by: 2) == [2, 4, 6, 8]
> (0 <.< 9).striding(by: 2) == [2, 4, 6, 8]
>
> (0 ... 9).striding(by: 3) == [0, 3, 6, 9]
> (0 ..< 9).striding(by: 3) == [0, 3, 6]
> (0 <.. 9).striding(by: 3) == [3, 6, 9]
> (0 <.< 9).striding(by: 3) == [3, 6]
>
> (0 ... 9).striding(by: -2) == [9, 7, 5, 3, 1]
> (0 ..< 9).striding(by: -2) == [7, 5, 3, 1]
> (0 <.. 9).striding(by: -2) == [9, 7, 5, 3, 1]
> (0 <.< 9).striding(by: -2) == [7, 5, 3, 1]
>
> (0 ... 9).striding(by: -3) == [9, 6, 3, 0]
> (0 ..< 9).striding(by: -3) == [6, 3, 0]
> (0 <.. 9).striding(by: -3) == [9, 6, 3]
> (0 <.< 9).striding(by: -3) == [6, 3]
> To reverse a stride, call reverse() on the results:
>
> (0 ... 9).striding(by: 2).reverse() == [8, 6, 4, 2, 0]
> We note that striding by 0 should be always be a precondition failure.
>
>
> <https://gist.github.com/erica/a51a981ee0352235204692affa959307#alternatives-considered>Alternatives
> Considered
>
> During the on-list discussion, we considered various scenarios that took
> closed/inclusive bounds into account or excluded open bounds for starting
> values. For example, we might have prohibited scenarios where multiple
> interpretations of an intended behavior might exist: is (0 ..<
> 9).striding(by: -2) a precondition failure? We settled on the simplest, most
> straight-forward implementation involving the fewest compiler warnings and
> the lowest likelihood of precondition failures. We subscribe to the "Dave
> Abrahams Philosophy": excessive special casing and warning scenarios more
> likely indicates bad language design than bad user comprehension.
>
>
> <https://gist.github.com/erica/a51a981ee0352235204692affa959307#future-directions>Future
> Directions
>
> We intend to follow up with an expanded operator vocabulary that includes
> fully open ranges (<.<), fully closed ranges (...) and both half open ranges
> (<.., ..<). These will support the full vocabulary laid out in the Detail
> Design section.
>
> Upon adoption, the Swift community may consider expanding this approach to
> collection indices, for example:
>
> let a = [8, 6, 7, 5, 3, 0, 9]
> for e in a.striding(by: 3) {
> print(e) // 8, then 5, then 9
> }
> Striding offers a fundamental operation over collections. The consistent
> approach introduced in this proposal
> <http://article.gmane.org/gmane.comp.lang.swift.evolution/13936> helps
> support the extension of stride semantics to collections.
>
>
> <https://gist.github.com/erica/a51a981ee0352235204692affa959307#acknowlegements>Acknowlegements
>
> Thanks, Dave Abrahams, Matthew Judge
>
> _______________________________________________
> swift-evolution mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
