<div dir="ltr">Yup, we&#39;re going to try to touch base, the authors of the current draft that is, sometime this week. More to come, hopefully.<div><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Apr 25, 2016 at 8:13 PM, Dave Abrahams via swift-evolution <span dir="ltr">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
on Mon Apr 11 2016, Dave Abrahams &lt;<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt; wrote:<br>
<br>
&gt; on Sun Apr 10 2016, Michel Fortin &lt;<a href="http://michel.fortin-AT-michelf.ca" rel="noreferrer" target="_blank">michel.fortin-AT-michelf.ca</a>&gt; wrote:<br>
&gt;<br>
&gt;&gt; So if you take this into account, storing the comparator as part of<br>
&gt;&gt; the stride makes the cost more predictable: not only there is one<br>
&gt;&gt; branch less in `next()`, but you avoid evaluating the condition which<br>
&gt;&gt; has an unknown cost: the `stride &lt; 0` part.<br>
&gt;&gt;<br>
&gt;&gt; And ideally you should make sure the optimizer can replace the<br>
&gt;&gt; indirect call with a direct call to the comparator. You do that by not<br>
&gt;&gt; making the comparator choice dependent on a runtime value, hence why I<br>
&gt;&gt; suggested having distinct &quot;down&quot; variants for the convenience<br>
&gt;&gt; functions: `stride(from:downTo:by:)` and<br>
&gt;&gt; `stride(from:downThrough:by:)` and `Range.strindingDown(by:)`.<br>
&gt;<br>
&gt; A few points:<br>
&gt;<br>
&gt; 1. There&#39;s a balance to be struck between making sure the optimizer can<br>
&gt;    do a good job under *absolutely all circumstances*, and keeping the<br>
&gt;    API surface area small and simple.  That makes me somewhat reluctant<br>
&gt;    to add “down” variants, if as I suspect the optimizer does well in<br>
&gt;    the vast majority of cases without them.<br>
&gt;<br>
&gt; 2. Similarly, I view r.striding(by: x) as redundant with stride(from: x,<br>
&gt;    to: y, by: z).  I&#39;d rather not have them both.<br>
&gt;<br>
&gt; 3. The fact that we&#39;re migrating C-style for loops to<br>
&gt;    uses of stride, as noted in <a href="https://github.com/apple/swift/pull/2125" rel="noreferrer" target="_blank">https://github.com/apple/swift/pull/2125</a>,<br>
&gt;    has convinced me that, sadly, we may need an answer that doesn&#39;t<br>
&gt;    involve ranges.  But maybe something like<br>
&gt;<br>
&gt;      for x in loop(from: 0.1, while: { $0 &lt; 10 }, next: { $0 + .2 })<br>
&gt;<br>
&gt;    is sufficient for this purpose.<br>
<br>
</div></div>After some reflection, I don&#39;t really want to see a construct like #3 in<br>
the standard library, and Chris has clarified for me that the standard<br>
library doesn&#39;t need to solve the migration problems created by the<br>
removal of C-style “for” loops.  So, if I have inadvertently killed<br>
progress on this proposal by bringing it up, please allow me to retract<br>
item 3 above.<br>
<br>
I&#39;d love to see the floating-point stride thing solved for Swift 3, but<br>
the window for changes is getting narrower, so if the community wants to<br>
move forward with the proposal (and implementation), that would be<br>
awesome.<br>
<br>
Cheers,<br>
<div class="HOEnZb"><div class="h5"><br>
--<br>
Dave<br>
<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">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>
</div></div></blockquote></div><br></div></div></div>