[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