<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">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.<div class=""><br class=""></div><div class="">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?<br class=""><div class="">
<br class="Apple-interchange-newline"><span style="color: rgb(0, 0, 0); font-family: 'Lucida Grande'; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; display: inline !important; float: none;" class="">Félix</span>
</div>
<br class=""><div><blockquote type="cite" class=""><div class="">Le 19 janv. 2016 à 15:46:00, Uwe Falck via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> a écrit :</div><br class="Apple-interchange-newline"><div class=""><div class="">I’m looking for feedback on this request if its worth to start an evolution proposal.<br class=""><br class=""><br class="">Let range operators always return empty ranges if the upper bound is smaller than the lower bound.<br class=""><br class=""> ####<br class=""><br class=""> Introduction<br class=""><br class=""> ####<br class=""><br class="">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. <br class=""><br class="">for i in 3..<3 <br class="">{ print(i) }<br class=""><br class="">for i in 3…2<br class="">{ print(i) }<br class=""><br class=""><br class=""> ####<br class=""><br class=""> Motivation<br class=""><br class=""> ####<br class=""><br class="">The two expressions above are mathematically equivalent and I would like them to return the same result for consistency.<br class=""><br class="">Furthermore, and more important: if C-style for loops are gone with Swift 3.0, programmers may translate <br class=""><br class="">func fibonacci(n: Int) -> Int { // works for n>=0<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>var memo = [0,1]<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>for var i = 2; i <= n; i++ {<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span>memo.append(memo[i-1] + memo[i-2])<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>}<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>return memo[n]<br class="">}<br class=""><br class="">probably into<br class=""><br class="">func fibonacci(n: Int) -> Int {<span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span>// works only for n>=2!<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>var memo = [0,1]<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>for i in 2...n {<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span>memo.append(memo[i-1] + memo[i-2])<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>}<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>return memo[n]<br class="">}<br class=""><br class="">This example is from Stackoverflow[1] with two suggested solutions to prevent the runtime error for 0 and 1<br class=""><br class="">let startIndex = 2<br class="">let endIndex = n<br class="">for i in startIndex.stride(through: endIndex, by: 1) {<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>memo.append(memo[i-1] + memo[i-2])<br class="">}<br class=""><br class="">…and another one uses the empty range generate by ..<<br class=""><br class="">for i in 2 ..< max(2, n+1) {<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>memo.append(memo[i-1] + memo[i-2])<br class="">}<br class=""><br class="">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.<br class=""><br class=""><br class=""> #####<br class=""><br class=""> Proposed solution<br class=""><br class=""> #####<br class=""><br class="">Let both range iterators return emtpy ranges, if end index < start index, and not only for a..<b with a==b.<br class=""><br class=""> #####<br class=""><br class=""> Impact on existing code<br class=""><br class=""> #####<br class=""><br class=""> None.<br class=""><br class=""> ####<br class=""><br class=""> Alternatives considered<br class=""><br class=""> ####<br class=""><br class=""> If range operators will allow downward variants this idea becomes pointless.<br class=""><br class=""> ####<br class=""><br class=""> Open questions<br class=""><br class=""> ####<br class=""><br class=""> None.<br class=""><br class=""><br class=""> [1] <a href="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" class="">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</a><br class=""><br class=""><br class=""> Thanks,<br class=""><br class=""><br class=""> --<br class=""><br class=""> Uwe<br class=""><br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></div></blockquote></div><br class=""></div></body></html>