[swift-evolution] Feature proposal: Range operator with step

[Xiaodi Wu]

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