Ah, I think the conceptual muddle arises in the plan then. Specifically, I'd argue that not all Ranges with Strideable bounds should conform to Collection.<br><br>Conceptually, whether a type can be advanced by some distance (guaranteed by Strideable) is orthogonal to whether a type has an obviously correct increment when calling next() on its iterator. Thus, although *strides* with Strideable bounds should obviously conform to Collection, Ranges that conform to Collection should be constrained to types which imply that the Range represents a countable set (as the mathematicians say) of numbers.<br><br>This distinction may come in handy for implementing strides that don't accumulate error. Striding through a Range that represents a countable set of elements shouldn't accumulate error and we can use what we already have--i.e. increment the current value every iteration without inspecting the value of the starting bound. Striding through a Range that represents an uncountable set of elements definitely requires reckoning from the starting bound every iteration.<br><div class="gmail_quote"><div dir="ltr">On Fri, Mar 25, 2016 at 11:25 AM Dave Abrahams via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
on Thu Mar 24 2016, Xiaodi Wu <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
<br>
> On Thu, Mar 24, 2016 at 4:18 PM, Dave Abrahams via swift-evolution<br>
> <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
>><br>
>> on Wed Mar 23 2016, Xiaodi Wu <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
>><br>
>>> So, in other words, you'd be satisfied with the following addition to<br>
>>> the standard library?<br>
><br>
>>><br>
>>> ```<br>
>>> extension Range where Element: Strideable {<br>
>>> func by(step: Element.Stride) -> StrideTo<Element> {<br>
>>> return startIndex.stride(to: endIndex, by: step)<br>
>>> }<br>
>>> }<br>
>>><br>
>>> /*<br>
>>> example of usage:<br>
>>><br>
>>> for i in (1..<10).by(2) {<br>
>>> print(i)<br>
>>> }<br>
>>> */<br>
>>> ```<br>
>><br>
>><br>
>> My current thinking is that:<br>
>><br>
>> * `for x in 0.0..<3.0 {}` should probably be an error, because 1.0 is<br>
>> not the obviously-right stride to use for non-integral numbers. That<br>
>> would imply that floating types should not conform to Strideable,<br>
>> which raises the question of whether Strideable should be folded into<br>
>> the Integer protocol.<br>
><br>
> Well, maybe I'm missing something, but `for x in 0.0..<3.0 { }`<br>
> doesn't work as it is, and it doesn't seem to have anything to do with<br>
> Strideable. Rather, HalfOpenInterval<Double> doesn't conform to<br>
> SequenceType.<br>
<br>
True, but the plan is that:<br>
<br>
* Interval is going away<br>
* Range will only require that its Bound be Comparable<br>
* Ranges with Strideable bounds will conform to Collection<br>
<br>
(see the swift-3-indexing-model branch on GitHub)<br>
<br>
> I agree that `for x in 0.0..<3.0 { }` should continue not working, but<br>
> maybe let's keep floating point types conforming to Strideable :)<br>
<br>
Those two things are not compatible with the plan we're going to<br>
propose, as described above.<br>
<br>
>><br>
>> * `for x in (0.0..<20.0).striding(by: 1.3) {}` should work without<br>
>> accumulating error<br>
>><br>
><br>
> +1.<br>
><br>
>> * `for x in 0..<3 {}` should work (obviously; that's the status quo)<br>
>><br>
>> * `for x in (0..<20).striding(by: 2)` should work<br>
>><br>
>> I think this might also handle the concerns that<br>
>> <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0051-stride-semantics.md" rel="noreferrer" target="_blank">https://github.com/apple/swift-evolution/blob/master/proposals/0051-stride-semantics.md</a><br>
>> was trying to address.<br>
>><br>
>> If I thought extreme concision was important for this application, I'd be<br>
>> proposing something like<br>
>><br>
>> for x in 0.0..<20.0//1.3 {}<br>
>><br>
>> but personally, I don't, which is why I propose `.striding(by: x)`<br>
>> rather than simply `.by(x)`, the latter being more open to<br>
>> misinterpretation.<br>
><br>
> Yeah, `.striding(by: x)` is pretty good.<br>
><br>
>><br>
>> --<br>
>> Dave<br>
>><br>
>> _______________________________________________<br>
>> swift-evolution mailing list<br>
>> <a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
>> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
> _______________________________________________<br>
> swift-evolution mailing list<br>
> <a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br>
--<br>
Dave<br>
<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div>