On Tue, Apr 5, 2016 at 4:28 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote: > > on Tue Apr 05 2016, Xiaodi Wu <swift-evolution@swift.org> 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. > 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 >> <swift-evolution@swift.org> wrote: >> >> on Tue Apr 05 2016, Xiaodi Wu >> <swift-evolution@swift.org> 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 >> > <dabrah...@apple.com> 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 >> > <dabrah...@apple.com> 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 >> > swift-evolution@swift.org >> > https://lists.swift.org/mailman/listinfo/swift-evolution >> >> -- >> Dave >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution > > -- > Dave > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
