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

[Howard Lovatt]

+1 from me. I have been caught by this. In the degenerate case I didn't
want the loop to be processed, but instead I got a runtime error. I solved
the problem by changing to a C style for loop, but with the removal of C
style for loops this will be more of a problem.

This could be solved with a library function as already suggested, however
having `...`, `..<`, `...?`, and `..<?` seems excessive. Therefore my
suggestion is to make `...` & `..<` behave as proposed (i.e. return empty
ranges when limits mean nothing enclosed by range).

On Wednesday, 20 January 2016, Félix Cloutier <swift-evolution at swift.org>
wrote:

> I don't have a strong opinion on this, but maybe there could be a
> ..<?/...? operator for ranges that may or may not be well-formed? This
> solution can be implemented "at home" too.
>
> I'd love to see where and how developers use ranges. It may be more
> helpful than it looks like. For instance, if you use a range to get an
> array slice, would your rather have an empty slice if your range underflows
> instead of the current error behavior?
>
> Félix
>
> Le 19 janv. 2016 à 15:46:00, Uwe Falck via swift-evolution <
> swift-evolution at swift.org
> <javascript:_e(%7B%7D,'cvml','swift-evolution at swift.org');>> a écrit :
>
> 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
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> <javascript:_e(%7B%7D,'cvml','swift-evolution at swift.org');>
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>

-- 
  -- Howard.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160120/6a8d46a9/attachment.html>