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

[Stephen Canon]

> On Apr 6, 2016, at 2:25 PM, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
> on Wed Apr 06 2016, Erica Sadun <erica-AT-ericasadun.com> wrote:
> 
>>    On Apr 6, 2016, at 3:05 PM, Dave Abrahams via swift-evolution
>>    <swift-evolution at swift.org> wrote:
>> 
>>    on Wed Apr 06 2016, Xiaodi Wu <xiaodi.wu-AT-gmail.com> wrote:
>> 
>>        On Wed, Apr 6, 2016 at 3:28 PM, Dave Abrahams via swift-evolution
>>        <swift-evolution at swift.org> wrote:
>> 
>>        You if you need to represent `<..` intervals in scientific computing,
>>            that's a pretty compelling argument for supporting them.
>> 
>>                        I'd like to be able to represent any of those as
>>                Intervals-which-are-now-Ranges. It makes sense to do so because
>>                the
>>                things I want to do with them, such as clamping and testing if
>>                some
>>                value is contained, are exactly what Intervals-now-Ranges
>>                provide.
>>                Looking around, it seems many other languages provide only what
>>                Swift
>>                currently does, but Perl does provide `..`, `..^`, `^..`, and
>>                `^..^`
>>                (which, brought over to Swift, would be `...`, `..<`, `<..`, and
>>                `<.<`).
>> 
>>            Do we need fully-open ranges too?
>> 
>>        I haven't encountered a need for open ranges, but I would expect that
>>        other applications in scientific computing could make use of them.
>>        I rather like Pyry's suggestions below. 
>> 
>>    Below?
>> 
>> Logically in time below.
> 
> Oh! In my application, time flows downward.
> 
>> 
>> I believe the following is a valid conversion of the Xiaodi Wu below into the
>> Dave A domain.
>> 
>>    On Apr 6, 2016, at 2:29 PM, Pyry Jahkola via swift-evolution
>>    <swift-evolution at swift.org> wrote:
>> 
>>    I think a sensible specification would be that with a positive step size,
>>    the count starts from the lower bound, and with a negative one, it starts
>>    from the upper bound (inclusive or exclusive). Thus, the following examples
>>    should cover all the corner cases:
>> 
>>    (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]
> 
> These all look reasonable to me.

Agreed.

– Steve