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

[Dave Abrahams]

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.

>     Lastly, if you want the positive stride reversed, you'd do just that:
>
>     (0 ... 9).striding(by: 2).reverse() == [8, 6, 4, 2, 0]

Also reasonable.

-- 
Dave