<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div></div><div>Good points!</div><div><br></div><div>-Thorsten&nbsp;</div><div><br>Am 25.03.2016 um 19:29 schrieb Xiaodi Wu via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt;:<br><br></div><blockquote type="cite"><div>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 &lt;<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt; 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 &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:<br>
<br>
&gt; On Thu, Mar 24, 2016 at 4:18 PM, Dave Abrahams via swift-evolution<br>
&gt; &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; on Wed Mar 23 2016, Xiaodi Wu &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt;&gt; So, in other words, you'd be satisfied with the following addition to<br>
&gt;&gt;&gt; the standard library?<br>
&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; ```<br>
&gt;&gt;&gt; extension Range where Element: Strideable {<br>
&gt;&gt;&gt;&nbsp; &nbsp; &nbsp;func by(step: Element.Stride) -&gt; StrideTo&lt;Element&gt; {<br>
&gt;&gt;&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;return startIndex.stride(to: endIndex, by: step)<br>
&gt;&gt;&gt;&nbsp; &nbsp; &nbsp;}<br>
&gt;&gt;&gt; }<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; /*<br>
&gt;&gt;&gt; example of usage:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; for i in (1..&lt;10).by(2) {<br>
&gt;&gt;&gt;&nbsp; &nbsp; &nbsp;print(i)<br>
&gt;&gt;&gt; }<br>
&gt;&gt;&gt; */<br>
&gt;&gt;&gt; ```<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; My current thinking is that:<br>
&gt;&gt;<br>
&gt;&gt; * `for x in 0.0..&lt;3.0 {}` should probably be an error, because 1.0 is<br>
&gt;&gt;&nbsp; &nbsp;not the obviously-right stride to use for non-integral numbers.&nbsp; That<br>
&gt;&gt;&nbsp; &nbsp;would imply that floating types should not conform to Strideable,<br>
&gt;&gt;&nbsp; &nbsp;which raises the question of whether Strideable should be folded into<br>
&gt;&gt;&nbsp; &nbsp;the Integer protocol.<br>
&gt;<br>
&gt; Well, maybe I'm missing something, but `for x in 0.0..&lt;3.0 { }`<br>
&gt; doesn't work as it is, and it doesn't seem to have anything to do with<br>
&gt; Strideable. Rather, HalfOpenInterval&lt;Double&gt; doesn't conform to<br>
&gt; 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>
&gt; I agree that `for x in 0.0..&lt;3.0 { }` should continue not working, but<br>
&gt; 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>
&gt;&gt;<br>
&gt;&gt; * `for x in (0.0..&lt;20.0).striding(by: 1.3) {}` should work without<br>
&gt;&gt;&nbsp; &nbsp;accumulating error<br>
&gt;&gt;<br>
&gt;<br>
&gt; +1.<br>
&gt;<br>
&gt;&gt; * `for x in 0..&lt;3 {}` should work (obviously; that's the status quo)<br>
&gt;&gt;<br>
&gt;&gt; * `for x in (0..&lt;20).striding(by: 2)` should work<br>
&gt;&gt;<br>
&gt;&gt; I think this might also handle the concerns that<br>
&gt;&gt; <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>
&gt;&gt; was trying to address.<br>
&gt;&gt;<br>
&gt;&gt; If I thought extreme concision was important for this application, I'd be<br>
&gt;&gt; proposing something like<br>
&gt;&gt;<br>
&gt;&gt;&nbsp; &nbsp;for x in 0.0..&lt;20.0//1.3 {}<br>
&gt;&gt;<br>
&gt;&gt; but personally, I don't, which is why I propose `.striding(by: x)`<br>
&gt;&gt; rather than simply `.by(x)`, the latter being more open to<br>
&gt;&gt; misinterpretation.<br>
&gt;<br>
&gt; Yeah, `.striding(by: x)` is pretty good.<br>
&gt;<br>
&gt;&gt;<br>
&gt;&gt; --<br>
&gt;&gt; Dave<br>
&gt;&gt;<br>
&gt;&gt; _______________________________________________<br>
&gt;&gt; swift-evolution mailing list<br>
&gt;&gt; <a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
&gt;&gt; <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
&gt; _______________________________________________<br>
&gt; swift-evolution mailing list<br>
&gt; <a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
&gt; <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>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></body></html>