<div dir="ltr">I agree with Kevin/Jordan, I also expect this to always be true:<div><br></div><span style="font-family:monospace,monospace"> Range<Int>(start: a, end: b).startIndex == a</span><br><div><span style="font-family:monospace,monospace"> </span><span style="font-family:monospace,monospace"> </span><font face="monospace, monospace">Range<Int>(start: a, end: b).endIndex == b</font></div><div><br></div><div>Possibly you could adjust Range to be something like this:</div><div><br></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"></blockquote><span style="font-family:monospace,monospace"> </span><span style="font-family:monospace,monospace">struct Range<T: ForwardIndexType> {</span><br><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"></blockquote><span style="font-family:monospace,monospace"> </span><span style="font-family:monospace,monospace"> </span><span style="font-family:monospace,monospace">var start: T</span>, <span style="font-family:monospace,monospace">end: T</span><br><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"></blockquote><span style="font-family:monospace,monospace"> </span><span style="font-family:monospace,monospace">}</span><div><font face="monospace, monospace"><br></font></div><div>Ensuring that this is true:</div><div><span style="font-family:monospace,monospace"> </span><span style="font-family:monospace,monospace"> </span><span style="font-family:monospace,monospace">Range<Int>(start: a, end: b).start == a</span><br><div><font face="monospace, monospace"> Range<Int>(start: a, end: b).end == b</font></div><div><br></div><div>Then startIndex and endIndex are simply for CollectionType conformance.</div><div><br></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"></blockquote><span style="font-family:monospace,monospace"> </span><span style="font-family:monospace,monospace">extension Range: CollectionType {</span><br><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"></blockquote><span style="font-family:monospace,monospace"> </span><span style="font-family:monospace,monospace"> var startIndex: T { return start }</span><br><span style="font-family:monospace,monospace"> </span><font face="monospace, monospace"> var endIndex: T { return start < end ? end : start }<br></font><span style="font-family:monospace,monospace"> </span><span style="font-family:monospace,monospace">}</span><div><div><br></div></div></div><div>You can still test the validity of the range:</div><div><font face="monospace, monospace"> assert(range.start < range.end)</font></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 21, 2016 at 8:23 AM, Jordan Rose 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">Mm. The reason '..<' doesn't have this behavior, though, is because you get the useful property that "collection[collection.startIndex..<collection.endIndex]" contains the same elements as "collection" itself. It's definitely useful to be able to represent an empty slice at a particular position (say, for replacing with another slice). It's a lot rarer to use '...' for slicing.<br>
<br>
Jordan<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
> On Jan 20, 2016, at 13:17 , Haravikk <<a href="mailto:me@haravikk.com">me@haravikk.com</a>> wrote:<br>
><br>
> I’m inclined to agree though I’m pretty uncertain all round.<br>
><br>
> To me it seems like the only cases where someone seems likely to end up with an end index lower than their start index is either from input (in which case the value should be tested first), or some kind of logic error, in which case silently failing isn’t going to help resolve that issue (or detect it).<br>
><br>
> Personally I’d much prefer the opposite solution, which would be to have stride throw an error if the range given is invalid; this would still mean both cases are consistent, but without the risk of silent failures ruining your program.<br>
><br>
> - Haravikk<br>
><br>
>> On 20 Jan 2016, at 19:42, Jordan Rose via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
>><br>
>> I'm a minor -1; it feels like this is in the same family as nil-messaging in that it can silently treat invalid input as a no-op. I'm not convinced that "upper bound less than the lower bound" is a strong enough signal for "empty" rather than "logic error". But it seems I'm in the minority.<br>
>><br>
>> Jordan<br>
>><br>
>><br>
>>> On Jan 19, 2016, at 12:46, Uwe Falck via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
>>><br>
>>> I’m looking for feedback on this request if its worth to start an evolution proposal.<br>
>>><br>
>>><br>
>>> Let range operators always return empty ranges if the upper bound is smaller than the lower bound.<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>
><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>