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

[Xiaodi Wu]

On Tue, Mar 29, 2016 at 7:48 PM, Dave Abrahams <dabrahams at apple.com> wrote:
>
> on Tue Mar 29 2016, Xiaodi Wu <xiaodi.wu-AT-gmail.com> wrote:
>
>> Relatedly, while you're tackling this big revision:
>>
>> I've tried to play around with what it would take to write a generic
>> non-error-accumulating striding method, and afaict, it would be
>> enormously cleaner if Strideable types are guaranteed to have + and *
>> (well, Strideable.Stride needs *, to be more accurate),
>
> That should happen automatically, since it conforms to SignedNumber,
> when we get the Integer protocols updated (project currently on hold while
> we land this other revision).
>
>> since the iterator needs to be able to compute end = start + iteration
>> * stride.
>
> Don't you need division too if you're going to do this?

I didn't seem to ever need division. See attached playground (which
borrows shamelessly from existing code and Erica's proposal, and which
is written in Swift 2.2 because that's what I had handy).

>
>> Is that going to be exposed somewhere in the cascade of numeric
>> protocols that culminate in Strideable?
>
> That's not in the plan.  I'm pretty sure we want UnsafePointer to be
> Strideable and we don't want it to have multiplication or division.

You're right. The type itself doesn't need to have multiplication or
division. In fact, writing this, I'm going back and changing my
playground a bit. It's sufficient that UnsafePointer.Stride can be
multiplied, and if SignedNumber conformance will guarantee
multiplication for all conforming types, we're all set for floating
point.

>
> I was thinking the StrideSequence (or some such) should be exposed as an
> associated type of the Strideable, so it can be as efficient as possible
> when no FP error is possible.  We don't want to spend divisions on
> striding over Ints.

Right, multiplication or division best avoided here. Not sure what the
associated type StrideSequence would be for though? Are you aiming for
one StrideTo type and one StrideThrough type instead of two apiece,
one for floating point and one for integer? I've been lazy and
overloading `stride(from:to:by:)` instead, but there's a lot of
repeated code.


>
>> On Mon, Mar 28, 2016 at 7:45 PM Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
>>
>>     on Mon Mar 28 2016, Dave Abrahams <swift-evolution at swift.org> wrote:
>>
>>     > on Mon Mar 28 2016, Erica Sadun <swift-evolution at swift.org> wrote:
>>     >
>>     >>> On Mar 28, 2016, at 3:54 PM, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
>>     >>>
>>     >>>
>>     >>> on Mon Mar 28 2016, Erica Sadun <swift-evolution at swift.org> wrote:
>>     >>>
>>     >>
>>     >>>>> On Mar 28, 2016, at 3:25 PM, Dave Abrahams via swift-evolution
>>     >>>>> <swift-evolution at swift.org> wrote:
>>     >>>>>
>>     >>>>>
>>     >>>>> on Mon Mar 28 2016, Xiaodi Wu
>>     >>>>
>>     >>>>> <swift-evolution at swift.org
>>     >>>>> <mailto:swift-evolution at swift.org>>
>>     >>>>> wrote:
>>     >>>>>
>>     >>>>>> Right, Countable could refine Strideable. I'm no expert on this, but
>>     >>>>>> some cursory reading suggests that the analogous feature in C++ simply
>>     >>>>>> requires the type to have operator++ defined. Obviously, that won't
>>     >>>>>> work for Swift 3.0...
>>     >>>>>
>>     >>>>> Hmm, instead of defining a new protocol (Countable), what if we just use
>>     >>>>> “Strideable where Stride : Integer” as a constraint?
>>     >>>>
>>     >>>> I like a differentiation between continuous and discrete things
>>     >>>> although both can have ranges, membership, fences,
>>     >>>> and a way to stride through them
>>     >>>
>>     >>> Strideable where Stride : Integer expresses just exactly that. Now if I
>>     >>> could only get the type-checker to cooperate...
>>     >>
>>     >> I am ridiculously excited about what you're doing there.
>>     >> Looking forward to beautiful floating point strides if for no
>>     >> other reason than I can point out how well they work for math
>>     >> in comparison to traditional for;;loops, so maybe people will
>>     >> stop burning semicolons on my lawn.
>>     >
>>     > The basics:
>>     > https://github.com/apple/swift/commit/a5c3c63c3d5d940f729c23aab342ea4d270d264a
>>
>>     Hi Erica,
>>
>>     After some consideration, while I want to see the smart
>>     (x..<y).striding(by: z) stuff happen too, it's somewhat incidental to
>>     the (already massive) project we're undertaking in this branch. Would
>>     you like to take on the implementation and/or proposal? I'd be happy to
>>     provide guidance.
>>
>>     --
>>     Dave
>>
>>     _______________________________________________
>>     swift-evolution mailing list
>>     swift-evolution at swift.org
>>     https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>
> --
> Dave
-------------- next part --------------
A non-text attachment was scrubbed...
Name: FloatingPointStrideTo.playground.zip
Type: application/zip
Size: 8922 bytes
Desc: not available
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160330/70d416ec/attachment.zip>