I agree with Taras that stride() and .striding() should coexist. -Thorsten
> Am 09.04.2016 um 01:01 schrieb Taras Zakharko via swift-evolution > <[email protected]>: > > I am agnostic on a .striding() method, but I am strongly agains any > suggestions of removing/replacing the global stride() function. The stride > function does not pollute the global namespace as it is a universally useful > construct (among others, for implementing classical iterating for loops), has > its history in contemporary programming (comparable functions in languages > like Python, R), and is IMO more readable and clear than a range with a > striding method method. Furthermore, a stride is not a range — its a special > sequence, while for ranges other rules apply. All in all, I don’t see why > stride() and .striding() can’t coexist. > > — Taras > > P.S. As a side note, I would prefer if the stride() function be renamed > sequence() or seq(), but thats just cosmetic personal preference. > > >> On 08 Apr 2016, at 20:37, Erica Sadun via swift-evolution >> <[email protected]> wrote: >> >> Draft here: 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) >> but we want to float this one first. >> >> Thanks, -- E >> >> >> >> Proposal: SE-XXXX >> Author(s): Xiaodi Wu, Pyry Jahkola, Nate Cook, Erica Sadun >> Status: TBD >> Review manager: TBD >> 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 thread. (Direct link to original thread) >> >> 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). >> >> 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. >> >> 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. >> >> 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 helps support the extension of stride >> semantics to collections. >> >> 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
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
