6 ms·
What do you like about it? I was actually thinking the opposite... EDIT: Genuinely curious, this is not meant to troll or start a war. I like the more explici
by cpfohl 9y ago
What do you like about it? I was actually thinking the opposite...
EDIT: Genuinely curious, this is not meant to troll or start a war.
I like the more explicit feeling `count-1`. I'd use either...
- seanwilson 9y agoIt confused me as well. "0.. is less than count"?
- GavinMcG 9y ago".." has a meaning – why are you leaving it out of the translation?
- seanwilson 9y agoI'd usually use ".." in the context of e.g. "2..3" to express a range but "<" to express a condition so I don't find it natural.
- Watabou 9y agoPersonally, I find that just having "0..count" requires a bit of thinking on my part trying to decide if it's inclusive or not. "0..<count" instantly tells me that it's not including value, and follows the matematical interval notification [0..count] vs [0..count)
- seanwilson 9y agoI'd prefer 0..count or 0..(count - 1) then.
- proyb2 9y agoI believe it was discussed in Swift Evolution, not confusing. 0...1 //0 to 1 Note: triple dot. 0..2 //error: repl.swift:1:2: error: use of unresolved operator '..' 0..<1 //0 to <1
- mikeash 9y agoAdd spaces for clarity: 0 ..< count I think Swift programmers should adopt this style.
- tomfitz 9y agoWhen I see "0..n" I wonder whether the range is inclusive or exclusive of n. When I see "0..<n" I know the range is exclusive of n.
- sillysaurus3 9y agoYes, but the corresponding design decision would be "0..=n". Swift's "0...n" is a bit less obvious. Also, exclusivity is almost always what you want, so "0..n" should just default to exclusivity and "0...n" could be inclusive.
- saghm 9y agoAs an alternative opinion, I personally hate when ranges are exclusive by default. In addition to it feeling somewhat unintuitive to me that I need to use range(0, 6) to include 5, it also makes downward ranges quite awkward, e.g. needing range(5, -1) to count from 5 to 0.
- dbaupp 9y agoExclusive by default is designed to fit with 0-based indexing (0..length(v), instead 0..(length(v)-1)). That said, this thinking is less relevant in languages with iterators/ranges and doubly so ones that offer a way to explicitly, but abstractly, iterate over the indices of a vector/array. On the point of downward ranges, you can often reverse the range explicitly, rather than swapping the endpoints, like reversed(range(0, 6)) or range(0, 6)[::-1] in Python (vs. range(5, -1, -1)). Of course, this isn't nearly as syntactically nice as range(5, 0)... but that comes with its own problems: automatically iterating backwards in ranges has been really annoying every time I've encountered it (mainly in R), requiring extra care and a pile of extra ifs and/or mins & maxs.
- saghm 9y agoI understand the benefits, I just personally don't prefer it. But this is just my subjective opinion.
- 9y ago
- ridiculous_fish 9y agoHow is the inclusive range operator implemented in Kotlin? Something like `for (i in 0..count)` needs to iterate count + 1 times, which may overflow the size of count's type - annoying to implement.
- kaeawc 9y agoIn Kotlin it's much more common to write the following, which is exclusive: count.forEach { // do things }
- chc 9y agoI don't see where the overflow would come into play since count is the terminal value and count is necessarily representable in its type.
- coldtea 9y ago>needs to iterate count + 1 times, which may overflow the size of count's type - annoying to implement How's that different from: for (int i=0; i<=count; i++) in e.g. C99?
- zem 9y agoit's always confusing, in languages with ranges, whether the range includes the second boundary element or not. it's purely a matter of convention, after all. ruby has a..b and a...b, but even after years of using the language i have to look up which is which. a..<b and a..b is perfect notation - once you know the language handles both cases, a..<b is very clearly "the range of numbers from a, and remaining strictly less than b", and "a..b" is "the range of numbers from a up to and including b". as for the "count - 1", it's not too bad because i find "inclusive" more intuitive than "exclusive" for the a..b notation, and that does make it explicit that you're not including b, but it's visual clutter in much the same way that having to iterate an array via "for i = 0 to len - 1" is.
- throwaway91111 9y agoWhy is it a..b instead of the logical a..=b or a..<=b?
- ves 9y agoYou only need to know that the language handles one explicitly, since there's two choices, so you might as well take the (more common | uglier to express) case and give it the "cleanest" special syntax: no special syntax.
- deleted 9y ago[deleted]
- deleted 9y ago[deleted]
- ptx 9y ago"a..b - 1" can also be written as "a until b" in Kotlin.
- Filligree 9y agoWhich is not as obvious. I much prefer a..<b.
- captaincrowbar 9y agoIn the early beta release of Swift 0.x, they used x..y for half-open ranges and x...y for closed ranges. This confused people (especially since Ruby already used the same operators but the other way around), so they changed the half-open operator to x..<y.
- deleted 9y ago[deleted]
- mikeash 9y ago0 ... count-1 fails when count is equal to the smallest value the type can represent (for example, if it's 0 and unsigned).