<div dir="ltr">I like the idea that Array gains `strinding(by:)` but would also like Range to be like an array, same interface, and hence also gain `strinding(by:)`, hence:<div><br></div><div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><span style="font-size:12.8px">calendar[(startDate ..< endDate).</span><span style="font-size:12.8px">striding(by: .Day)]</span><br></div></blockquote></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"> -- Howard.<br></div></div>
<br><div class="gmail_quote">On 7 April 2016 at 10:53, 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"><br>
on Wed Apr 06 2016, Brent Royal-Gordon <brent-AT-architechies.com> wrote:<br>
<br>
>> I (am familiar with and) agree with Dijkstra's logic, but not with your<br>
>> conclusion about it. The fact that one representation is more natural<br>
>> for most common computing tasks doesn't mean it's not worth supporting<br>
>> the other representations.<br>
><br>
> I'm not saying that Dijkstra proves that we don't need any other range<br>
> operators. Rather, I'm saying that he demonstrates why supporting<br>
> `..<` but not `<..` is not arbitrary or capricious. Dijkstra's<br>
> argument *permits* us to privilege `..<` as uniquely important, but<br>
> doesn't *force* us to do so.<br>
<br>
I agree. And I still think it's uniquely important ;-).<br>
<br>
> To another person just now, you said:<br>
><br>
>> He was talking about ranges of integer indices, though, and even<br>
>> more-specifically about how to address arrays. Range<Bound> is a more<br>
>> general concept that applies to much more than indices. Once you<br>
>> involve floating point (and rationals, and patterns for matching,<br>
>> e.g. UnicodeScalar("a")..."z"), the conclusions no longer apply.<br>
><br>
> I actually think he was talking a little more broadly than<br>
> that—essentially, he was discussing ordered, discrete types. In<br>
> principle, the same argument applies to UnicodeScalars,<br>
<br>
Yes, but I don't know if he had such types.<br>
<br>
> but not to floating-point numbers (unless you use treat floats as a<br>
> discrete type using `nextafter` as the `successor()` operation, which<br>
> is coherent but not very useful in practice). Having said that, I *do*<br>
> think that `...` is in practice quite useful for many types. I'm less<br>
> certain that `<..` or `<.<` are.<br>
><br>
> * * *<br>
><br>
> By the way, another reason to have `stride` as a free function is that<br>
> I think some types need a "strider", an instance which performs the<br>
> striding.<br>
><br>
> That was the conclusion I came to when I started experimenting with<br>
> striding over NSDates a week or two ago. The best design I could come<br>
> up with looked like this:<br>
><br>
> calendar.using(.Day).stride(from: startDate, to: endDate, by: 1)<br>
<br>
> The `start` and `end` parameters could be grouped together into a<br>
> single parameter to match `stride(over:by:)`, but you can't put the<br>
> calendar or the unit into the stride—without them, there is no<br>
> coherent way to calculate the distance between two dates.<br>
><br>
> So if some types need a strider, and will need to have the method<br>
> structured as `strider.stride(something:by:)`, it seems like the free<br>
> function version for types which *don't* need a strider ought to be<br>
> `stride(something:by:)`. The `something.striding(by:)` design can't be<br>
> easily adapted to this situation.<br>
<br>
calendar[startDate..<endDate].striding(by: .Day)<br>
<br>
?<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Dave<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>
</font></span></blockquote></div><br></div>