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

Dave Abrahams dabrahams at apple.com
Tue Apr 5 16:28:07 CDT 2016


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.  

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



More information about the swift-evolution mailing list