[swift-evolution] [Proposal] Decoupling Floating Point Strides from Generic Implementations
Erica Sadun
erica at ericasadun.com
Tue Mar 1 10:46:08 CST 2016
> On Mar 1, 2016, at 3:56 AM, Brent Royal-Gordon <brent at architechies.com> wrote:
>
>> If one were looking for a quick and dirty fix, the same kind of math used in this rough solution (let value = start + count * interval) could be adopted back into the current generic implementation.
>
> I notice that `start + count * interval` would actually work with `Int`, too.
>
> I wonder if we might be better off introducing a sub-protocol of `Strideable` which can advance several increments at a time:
>
> protocol RandomStrideable: Strideable {
> func advancedBy(n: Self.Distance, times: Int) -> Self
> }
>
> extension RandomStrideable {
> func stride(to end: Self, by: Distance) -> RandomStrideTo<Self> { ... }
> func stride(through end: Self, by: Distance) -> RandomStrideThrough { ... }
> }
>
> `Double` and `Int` can both conform to `RandomStrideable`; types which cannot do this (*are* there any types which cannot do this?) can conform to `Strideable`.
>
> Alternatively, if we actually *prefer* the repeated-advance implementation and we're only using this multiplication-based one because we have to, `Strideable` can be the new multiplication-based protocol and `IncrementalStrideable` can be a subprotocol which supports repeated-advance.
>
> --
> Brent Royal-Gordon
> Architechies
>
If you adopt a better algorithm, like the one in the updated proposal (https://gist.github.com/erica/cf50f3dc54bb3a090933),
would it still make sense to do this? The one time set-up for the generator is "expensive" if run at each access this way.
-- Erica
More information about the swift-evolution
mailing list