[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