on Tue Mar 29 2016, Xiaodi Wu <xiaodi.wu-AT-gmail.com> wrote: > On Tue, Mar 29, 2016 at 7:48 PM, Dave Abrahams <dabrah...@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).
I guess it depends what semantics you want. Maybe the semantics that need division are better suited to a different API: (a..<b).striding(stepCount: 10) >>> 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? Well, the multiplications can likely be optimized away, so maybe it's a non-issue. It's really worth looking at the code you get at -O, to see if we can avoid complicating the API. The thinking was that a Strideable type could have a StrideSequence with a default of StrideByAdding<Self>, while FloatingPoint types would use StrideSequence = StrideByMultiplying<Self>. > Are you aiming for one StrideTo type and one StrideThrough type > instead of two apiece Either way would be reasonable, depending on how well it optimizes. > , one for floating point and one for integer? No, one for FP and one for most everything else. > 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@swift.org> wrote: >>> >>> on Mon Mar 28 2016, Dave Abrahams <swift-evolution@swift.org> wrote: >>> >>> > on Mon Mar 28 2016, Erica Sadun <swift-evolution@swift.org> wrote: >>> > >>> >>> On Mar 28, 2016, at 3:54 PM, Dave Abrahams via swift-evolution >>> <swift-evolution@swift.org> wrote: >>> >>> >>> >>> >>> >>> on Mon Mar 28 2016, Erica Sadun <swift-evolution@swift.org> wrote: >>> >>> >>> >> >>> >>>>> On Mar 28, 2016, at 3:25 PM, Dave Abrahams via swift-evolution >>> >>>>> <swift-evolution@swift.org> wrote: >>> >>>>> >>> >>>>> >>> >>>>> on Mon Mar 28 2016, Xiaodi Wu >>> >>>> >>> >>>>> <swift-evolution@swift.org >>> >>>>> <mailto:swift-evolution@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@swift.org >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> >> >> -- >> Dave > -- Dave _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution