on Tue Apr 05 2016, Xiaodi Wu <xiaodi.wu-AT-gmail.com> wrote: > On Tue, Apr 5, 2016 at 4:28 PM, Dave Abrahams via swift-evolution > <[email protected]> wrote: >> >> on Tue Apr 05 2016, Xiaodi Wu <[email protected]> wrote: >> >>> Right. I would argue that `(a+s...b).striding(by: s).reversed` is a great >>> deal >>> less readable than `stride(from: b, to: a, by: -s)`. And since the latter >>> is the >>> status quo, I would say that it's a point against restricting strides to the >>> proposed syntax. >> >> Yes, those are all points. But it totally avoids the question of >> whether the case of striding over an inverted half-open range by a >> negative step is an important enough case to be worth complicating the >> library to make it readable. > > At the risk of tedious pedantry-- > > Given that this discussion was spawned from one about Swift's for > loop, it would be remiss not to circle back and point out that what's > at issue isn't a matter of complicating an existing implementation to > support stride to (or, striding over an inverted half-open range) with > negative stride size, but rather whether a proposed simplification > ought to be implemented that removes this already supported use case. > IMO, the existing implementation is not overly inelegant, and deep in > the logic of StrideToIterator is an if statement (using a ternary > operator in the expression, no less!) to account for negative stride > size--so I can only conclude that its being supported isn't merely a > happy byproduct of the current implementation but very much an > explicitly planned-for feature.
I fully agree that negative strides ought to be supported, e.g. r.striding(by: -d) >> If it is important enough, I am much more inclined to support >> >> (a<..b).striding(by: s).reversed >> >> or >> >> (a<..b).striding(by: -s) // i.e., negative strides automatically reverse >> >> simply because it makes a presumably-useful concept available (inverse >> half-open range), re-uses existing syntax, and doesn't bring up these >> naming questions. >> >> Frankly, >> >> (a+s...b).striding(by: -s) >> >> isn't all that bad. >> >>> On Tue, Apr 5, 2016 at 3:57 PM Dave Abrahams via swift-evolution >>> <[email protected]> wrote: >>> >>> on Tue Apr 05 2016, Xiaodi Wu >>> <[email protected]> wrote: >>> >>> > Certainly, for integer literals and strides of -1. >>> > >>> > I meant more generally that removal of stride(...) will eliminate the >>> > possibility of striding to but not through arbitrary half-open >>> intervals >>> (a, b], >>> > where a < b, by a negative increment, because there is no such thing >>> as >>> `a>..b` >>> > to express such an interval as a Swift range. >>> > Of course, all such cases can be handled by adjusting the endpoint and >>> using a >>> > closed range instead >>> > >>> >>> Indeed, if b - a is a multiple of s, >>> >>> (a+s...b).striding(by: s).reversed >>> >>> works. >>> >>> The question is whether this case is important enough to create a >>> special family of functions for, and then deal with the naming issues >>> raised by >>> >>> https://github.com/apple/swift-evolution/blob/master/proposals/0051-stride-semantics.md >>> >>> ? >>> >>> > On Tue, Apr 5, 2016 at 2:54 PM Dave Abrahams >>> > <[email protected]> wrote: >>> > >>> > on Tue Apr 05 2016, Xiaodi Wu <xiaodi.wu-AT-gmail.com> wrote: >>> > >>> > > On Mon, Apr 4, 2016 at 1:22 PM, Dave Abrahams >>> > <[email protected]> wrote: >>> > >> >>> > >> on Sat Apr 02 2016, Xiaodi Wu <xiaodi.wu-AT-gmail.com> wrote: >>> > >> >>> > >>> [snip] >>> > >>> >>> > >>> Not included: >>> > >>> 1. I know Ranges are in flux, so I've held off on extending Range >>> with >>> > >>> a striding(by:) method in this proof-of-concept. >>> > >> >>> > >> They're not in flux, except for not having been reviewed yet; they >>> are >>> > >> settled in the swift-3-indexing-model branch. >>> > > >>> > > Did not know that. Will have to study what's there in more detail. >>> > > >>> > >>> 2. No attempt at the suggested stride(from:to:steps:) quite yet. >>> > >> >>> > >> #1 and #2 are mutually exclusive; we prefer #1 as it removes >>> questions >>> > >> about the meaning of "to" or "through." >>> > > >>> > > I wasn't aware that was the thinking. Limiting strides to >>> > > `striding(by:)` removes the ability to express `stride(from: 0, to: >>> > > -10, by: -1)` >>> > >>> > IMO this: >>> > >>> > (-9...0).reverse() >>> > >>> > is better than >>> > >>> > stride(from: 0, to: -10, by: -1) >>> > >>> > What do you think? >>> > >>> > -- >>> > Dave >>> > >>> > _______________________________________________ >>> > swift-evolution mailing list >>> > [email protected] >>> > https://lists.swift.org/mailman/listinfo/swift-evolution >>> >>> -- >>> Dave >>> >>> _______________________________________________ >>> 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 >> >> -- >> Dave >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution -- Dave _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
