<div dir="ltr">Yup, we'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"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></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 <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
<br>
> on Sun Apr 10 2016, Michel Fortin <<a href="http://michel.fortin-AT-michelf.ca" rel="noreferrer" target="_blank">michel.fortin-AT-michelf.ca</a>> wrote:<br>
><br>
>> So if you take this into account, storing the comparator as part of<br>
>> the stride makes the cost more predictable: not only there is one<br>
>> branch less in `next()`, but you avoid evaluating the condition which<br>
>> has an unknown cost: the `stride < 0` part.<br>
>><br>
>> And ideally you should make sure the optimizer can replace the<br>
>> indirect call with a direct call to the comparator. You do that by not<br>
>> making the comparator choice dependent on a runtime value, hence why I<br>
>> suggested having distinct "down" variants for the convenience<br>
>> functions: `stride(from:downTo:by:)` and<br>
>> `stride(from:downThrough:by:)` and `Range.strindingDown(by:)`.<br>
><br>
> A few points:<br>
><br>
> 1. There's a balance to be struck between making sure the optimizer can<br>
> do a good job under *absolutely all circumstances*, and keeping the<br>
> API surface area small and simple. That makes me somewhat reluctant<br>
> to add “down” variants, if as I suspect the optimizer does well in<br>
> the vast majority of cases without them.<br>
><br>
> 2. Similarly, I view r.striding(by: x) as redundant with stride(from: x,<br>
> to: y, by: z). I'd rather not have them both.<br>
><br>
> 3. The fact that we're migrating C-style for loops to<br>
> 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>
> has convinced me that, sadly, we may need an answer that doesn't<br>
> involve ranges. But maybe something like<br>
><br>
> for x in loop(from: 0.1, while: { $0 < 10 }, next: { $0 + .2 })<br>
><br>
> is sufficient for this purpose.<br>
<br>
</div></div>After some reflection, I don'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'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'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>