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

[Dave Abrahams]

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
> <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.

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
>>> <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

-- 
Dave