> 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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
