Piling on because it would really help to get a sense of what direction the core team is looking for. Unless we can figure out in advance what the core team is actually looking for, it's hard to respond with the request for revision. The feedback says: "they don't think this API change is the right approach" and "The core team believes that the existing strideable API cannot efficiently and correctly handle all the real-world use cases one would want."
I'd like to iterate the design as requested, but it's hard to know where to start. So let me discuss things that can be strode along:
There are four types of bounded intervals (open and closed on each end) that can be traversed in either direction, four types of unbounded interval (open and closed starting points, heading positively and negatively), and both integer and floating point applications of strides along these:
Bounded Intervals: [A, B), (A, B], (A, B), [A, B]
Unbounded Intervals: (A, ∞), [A, ∞), ( -∞, A), (-∞, A]
(Technically, there's also the empty interval (), and the full number line (-∞, ∞), which really don't come into play for sequences but might play a role in pattern matching.)
The simplest API to handle all these cases would be:
`stride(from/off:, by:, towards/to/through:)` for sequences along bounded intervals and
`stride(from/off:, by:)` for sequences along unbounded intervals.
In these calls, `from` is inclusive and `off` is exclusive of the first value.
SE-0051 <https://github.com/apple/swift-evolution/blob/master/proposals/0051-stride-semantics.md> covers the details of what the semantics of `towards`/`to`/`through` mean:
towards meaning a..<b, a<..b, for example: 1 towards 5 by 1 is [1, 2, 3, 4]
to a...b, for example: 1 to 5 by 1 is [1, 2, 3, 4, 5], and 1 to 10 by 8 is [1, 9]
through a..>=b, a>=..b, for example: 1 through 5 by 1 is [1, 2, 3, 4, 5] and 1 through 10 by 8 is [1, 9, 17]
The acceptance of SE-0045 and SE-0099 and makes implementing each of these sequence types much easier. The state version can use the error-reducing iteration multiplier. The non-state version is perfect for integer math.
On May 30, 2016, at 4:10 AM, Brent Royal-Gordon via swift-evolution <firstname.lastname@example.org> wrote:
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?