Like it! -Thorsten
Am 30.05.2016 um 12:10 schrieb Brent Royal-Gordon via swift-evolution <[email protected]>: >> 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 _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
