Swift is designed to make many common C and Objective-C errors less likely, but at least one class of bugs could be ascendant: off-by-one errors in ranges. Swif

Swift is designed to make many common C and Objective-C errors less likely, but at least one class of bugs could be ascendant: off-by-one errors in ranges. Swift's ".." and "..." range operators are reversed compared to Ruby and CoffeeScript. Swift's way is arguably more sensible: the longer operator makes a longer range. But switching the way two similar-looking operators work, as opposed to at least two other languages popular with the target audience, is bound to lead to errors as programmers switch contexts. Just the fact of having the two operators in the language together is dangerous, since they look similar and switching them will lead to weird bugs instead of immediate compile-time or runtime errors. Switching their meanings makes this more pernicious. Time to prime our eyeballs to look out for this one. [1] Swift book: “Use .. to make a range that omits its upper value, and use ... to make a range that includes both values.” Excerpt From: Apple Inc. “The Swift Programming Language.” iBooks. https://itun.es/us/jEUH0.l https://itun.es/us/jEUH0.l [2] Ruby: "Ranges constructed using .. run from the beginning to the end inclusively. Those created using ... exclude the end value." [http://www.ruby-doc.org/core-2.1.2/Range.html http://www.ruby-doc.org/core-2.1.2/Range.html] [3] CoffeeScript: "With two dots (3..6), the range is inclusive (3, 4, 5, 6); with three dots (3...6), the range excludes the end (3, 4, 5)".