Dijkstra specifically said that in Mesa it was a bad idea to include anything other than `..<` the relevent quote is:<div><br></div><div>"<font size="2"><span style="background-color:rgba(255,255,255,0)">Extensive experience with Mesa has shown that the use of the other three conventions has been a constant source of clumsiness and mistakes, and on account of that experience Mesa programmers are now strongly advised not to use the latter three available features. I mention this experimental evidence —for what it is worth— because some people feel uncomfortable with conclusions that have not been confirmed in practice."</span></font></div><div><font size="2"><span style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.301961);"><br></span></font></div><div><font size="2"><span style="background-color:rgba(255,255,255,0)"></span><span style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.301961);">In the above quote the first convention is `..<` and the other three are `<..`, `...`, and `<.<` respectively. Therefore he is suggesting that even `...` should not be included.</span></font></div><div><font size="2"><span style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.301961);"><br></span></font></div><div><font size="2"><span style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.301961);">Personally I would go against Dijksra's advice and include all 4 as operators, however if Dijkstra is followed and only `..<` remains then the 'lesser' cases could be covered with an init on Range:</span></font></div><div><font size="2"><span style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.301961);"><br></span></font></div><div><font size="2"><span style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.301961);"> init Range(first: T, isFirstIncluded: Bool = true, last: T, isLastIncluded: Bool = true, stride: Int = 1)<br></span></font><br>On Thursday, 7 April 2016, Dave Abrahams via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> 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 <<a href="javascript:;" onclick="_e(event, 'cvml', 'swift-evolution@swift.org')">swift-evolution@swift.org</a>> wrote:<br>
<br>
>> From a purely numerically aesthetic point of view, I'd much prefer ranges to be<br>
>> openable and closable at both ends.<br>
>><br>
>> My primary use-case has been teaching math using playgrounds but I'm sure<br>
>> there are lots of other real-world situations more specific to common numerical<br>
>> method tasks.<br>
><br>
> By coincidence, a Perl hacker I know commented on Twitter yesterday<br>
> that he thought 1-based arrays were the way to go in the 21st<br>
> century. Somebody replying to that suggestion linked to a note by<br>
> Dijkstra that's relevant to this conversation:<br>
> <<a href="https://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/EWD831.html" target="_blank">https://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/EWD831.html</a>><br>
><br>
> I'd suggest everyone in this discussion should read it—it's only about 700 words—but to summarize:<br>
><br>
> 1. The semantic Swift refers to as `..<` is the most natural range convention.<br>
> 2. Relatedly, zero-based indexing is the most natural indexing convention.<br>
><br>
> If we agree with Dijkstra's logic, then the only reason to support<br>
> `>..` is for ranges where start > end—that is, when we're constructing<br>
> a reversed range.<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>
> But if we decide to support striding backwards by using a forward<br>
> range and a negative stride, then that covers the reverse use<br>
> case. Thus, we would need neither additional range operators, nor<br>
> reversed ranges.<br>
><br>
> As for the `range.striding(by:)` vs `stride(over:by:)` question, my<br>
> concerns there are, to be honest, mainly aesthetic. The need for<br>
> parentheses around the range operator is more or less unavoidable, but<br>
> I think they make the construct very ugly. However, I also think that<br>
> the `stride(over:by:)` syntax (or, for that matter<br>
> `stride(from:to:by:)`) look more constructor-y (they are only *not*<br>
> constructors now because of the overloading), and I think it opens us<br>
> up to parallel constructs like the `induce(from:while:by:)` function<br>
> I've been working on.<br>
<br>
--<br>
Dave<br>
<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="javascript:;" onclick="_e(event, 'cvml', 'swift-evolution@swift.org')">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div><br><br>-- <br>-- Howard.<br>