[swift-evolution] Feature proposal: Range operator with step
xiaodi.wu at gmail.com
Tue Apr 5 15:26:52 CDT 2016
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, but the same can be said for all half-open
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>
> >> 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:
> is better than
> stride(from: 0, to: -10, by: -1)
> What do you think?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution