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

[Xiaodi Wu]

Ah, I think the conceptual muddle arises in the plan then. Specifically,
I'd argue that not all Ranges with Strideable bounds should conform to
Collection.

Conceptually, whether a type can be advanced by some distance (guaranteed
by Strideable) is orthogonal to whether a type has an obviously correct
increment when calling next() on its iterator. Thus, although *strides*
with Strideable bounds should obviously conform to Collection, Ranges that
conform to Collection should be constrained to types which imply that the
Range represents a countable set (as the mathematicians say) of numbers.

This distinction may come in handy for implementing strides that don't
accumulate error. Striding through a Range that represents a countable set
of elements shouldn't accumulate error and we can use what we already
have--i.e. increment the current value every iteration without inspecting
the value of the starting bound. Striding through a Range that represents
an uncountable set of elements definitely requires reckoning from the
starting bound every iteration.
On Fri, Mar 25, 2016 at 11:25 AM Dave Abrahams via swift-evolution <
swift-evolution at swift.org> wrote:

>
> on Thu Mar 24 2016, Xiaodi Wu <swift-evolution at swift.org> wrote:
>
> > On Thu, Mar 24, 2016 at 4:18 PM, Dave Abrahams via swift-evolution
> > <swift-evolution at swift.org> wrote:
> >>
> >> on Wed Mar 23 2016, Xiaodi Wu <swift-evolution at swift.org> wrote:
> >>
> >>> So, in other words, you'd be satisfied with the following addition to
> >>> the standard library?
> >
> >>>
> >>> ```
> >>> extension Range where Element: Strideable {
> >>>     func by(step: Element.Stride) -> StrideTo<Element> {
> >>>         return startIndex.stride(to: endIndex, by: step)
> >>>     }
> >>> }
> >>>
> >>> /*
> >>> example of usage:
> >>>
> >>> for i in (1..<10).by(2) {
> >>>     print(i)
> >>> }
> >>> */
> >>> ```
> >>
> >>
> >> My current thinking is that:
> >>
> >> * `for x in 0.0..<3.0 {}` should probably be an error, because 1.0 is
> >>   not the obviously-right stride to use for non-integral numbers.  That
> >>   would imply that floating types should not conform to Strideable,
> >>   which raises the question of whether Strideable should be folded into
> >>   the Integer protocol.
> >
> > Well, maybe I'm missing something, but `for x in 0.0..<3.0 { }`
> > doesn't work as it is, and it doesn't seem to have anything to do with
> > Strideable. Rather, HalfOpenInterval<Double> doesn't conform to
> > SequenceType.
>
> True, but the plan is that:
>
> * Interval is going away
> * Range will only require that its Bound be Comparable
> * Ranges with Strideable bounds will conform to Collection
>
> (see the swift-3-indexing-model branch on GitHub)
>
> > I agree that `for x in 0.0..<3.0 { }` should continue not working, but
> > maybe let's keep floating point types conforming to Strideable :)
>
> Those two things are not compatible with the plan we're going to
> propose, as described above.
>
> >>
> >> * `for x in (0.0..<20.0).striding(by: 1.3) {}` should work without
> >>   accumulating error
> >>
> >
> > +1.
> >
> >> * `for x in 0..<3 {}` should work (obviously; that's the status quo)
> >>
> >> * `for x in (0..<20).striding(by: 2)` should work
> >>
> >> I think this might also handle the concerns that
> >>
> https://github.com/apple/swift-evolution/blob/master/proposals/0051-stride-semantics.md
> >> was trying to address.
> >>
> >> If I thought extreme concision was important for this application, I'd
> be
> >> proposing something like
> >>
> >>   for x in 0.0..<20.0//1.3 {}
> >>
> >> but personally, I don't, which is why I propose `.striding(by: x)`
> >> rather than simply `.by(x)`, the latter being more open to
> >> misinterpretation.
> >
> > Yeah, `.striding(by: x)` is pretty good.
> >
> >>
> >> --
> >> 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
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160325/085ccb57/attachment.html>