[swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0050: Decoupling Floating Point Strides from Generic Implementations

[Brent Royal-Gordon]

> The core team believes that the existing strideable API cannot efficiently and correctly handle all the real-world use cases one would want.  However, a multiplication-based implementation similar to the one proposed in SE-0050 (but potentially extended) seems sufficiently general to solve the existing use cases as well as solve the floating point error accumulation issue.  Once the design of this iterates on swift-evolution, it would be great to see a revised version of this proposal.

Can you give any indication of what's wrong with the proposed API?

Personally, what bothered me about it is that it seems too float-specific. The way I would design it is to add multiplication to Strideable:

	public protocol Strideable: Comparable {
		typealias Stride: SignedNumber
		
		func distance(to other: Self) -> Stride
		func advanced(by stride: Stride) -> Self
		
		static func scale(_ stride: Stride, by multiplier: Stride) -> Stride
	}

And then have a refined protocol for types like Int which are safe to repeatedly advance:

	/// An AccumulatingStrideable is a Strideable which guarantees that:
	///
	///	(0..<10).reduce(value) { val, _ in val.advanced(by: stride) } == value.advanced(by: T.scale(stride, by: 10))
	/// 
	/// In other words, the result of repeatedly advancing any value by any stride *n* times is exactly equal to the 
	/// result of advancing it once by that stride scaled up *n* times.
	public protocol AccumulatingStrideable: Strideable {}

Then you have two forms of `stride(from:to:by:)`:

	public func stride<T: Strideable>(from start: T, to end: T, by stride: T.Stride) -> StrideTo<T>
	public func stride<T: AccumulatingStrideable>(from start: T, to end: T, by stride: T.Stride) -> AccumulatingStrideTo<T>

Obviously there are many designs we could consider along these lines, and I don't want to get bogged down in the details of choosing one at this point. What I'm asking is, is this the general *kind* of design you're looking for compared to SE-0050, one which is not specific to FloatingPoint types? Or are you looking for a redesign which addresses different issues from these?

-- 
Brent Royal-Gordon
Architechies