[swift-evolution] Let range operators always return empty ranges if the upper bound is smaller than the lower bound.

[Jordan Rose]

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.

Jordan


> On Jan 20, 2016, at 13:17 , Haravikk <me at haravikk.com> wrote:
> 
> I’m inclined to agree though I’m pretty uncertain all round.
> 
> 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).
> 
> 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.
> 
> - Haravikk
> 
>> On 20 Jan 2016, at 19:42, Jordan Rose via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> 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.
>> 
>> Jordan
>> 
>> 
>>> On Jan 19, 2016, at 12:46, Uwe Falck via swift-evolution <swift-evolution at swift.org> wrote:
>>> 
>>> I’m looking for feedback on this request if its worth to start an evolution proposal.
>>> 
>>> 
>>> Let range operators always return empty ranges if the upper bound is smaller than the lower bound.
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>