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

[Uwe Falck]

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.

 ####

 Introduction

 ####

Consider two loops. The first loop iterator will return an empty range and will not be executed. The second loop throws an error. I would like to see the range iterator always returning an empty range if end index < start index. 

for i in 3..<3 
{ print(i) }

for i in 3…2
{ print(i) }


 ####

 Motivation

 ####

The two expressions above are mathematically equivalent and I would like them to return the same result for consistency.

Furthermore, and more important: if C-style for loops are gone with Swift 3.0, programmers may translate 

func fibonacci(n: Int) -> Int {                            // works for n>=0
	var memo = [0,1]
	for var i = 2; i <= n; i++ {
		memo.append(memo[i-1] + memo[i-2])
	}
	return memo[n]
}

probably into

func fibonacci(n: Int) -> Int {				// works only for n>=2!
	var memo = [0,1]
	for i in 2...n {
		memo.append(memo[i-1] + memo[i-2])
	}
	return memo[n]
}

This example is from Stackoverflow[1] with two suggested solutions to prevent the runtime error for 0 and 1

let startIndex = 2
let endIndex = n
for i in startIndex.stride(through: endIndex, by: 1) {
	memo.append(memo[i-1] + memo[i-2])
}

…and another one uses the empty range generate by  ..<

for i in 2 ..< max(2, n+1) {
	memo.append(memo[i-1] + memo[i-2])
}

Clearly the not-working-solution looks most logical. All other control flow elements, like while, will just not execute if their condition is not met on loop entry.


 #####

 Proposed solution

 #####

Let both range iterators return emtpy ranges, if end index < start index, and not only for a..<b with a==b.
 
 #####

 Impact on existing code

 #####

 None.

 ####

 Alternatives considered

 ####

 If range operators will allow downward variants this idea becomes pointless.

 ####

 Open questions

 ####

 None.


 [1] http://stackoverflow.com/questions/34323227/a-concise-way-to-not-execute-a-loop-now-that-c-style-for-loops-are-going-to-be-r?lq=1
 

 Thanks,


 --

 Uwe