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

[Thorsten Seitz]

> Am 06.04.2016 um 23:26 schrieb Stephen Canon via swift-evolution <swift-evolution at swift.org>:
> 
> 
>> 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.

I agree as well. Makes sense.

-Thorsten