31–40 of 364 posts
0..<count is a lovely little piece of language design
I can't tell whether this is sarcasm or not. What does the '<' mean in this case? I'm assuming an exclusive upper bound.
0..<count is a lovely little piece of language design
An alternative approach is Guava's Range class: Range.closed(1,5) == [1,5] Range.open(1,5) == (1,5) Range.openClosed(1,5) == (1,5] Range.closedOpen(1,5) == [1,5) Range.greaterThan(1) == (1,infinity) Range.atLeast(1) == [1,infinity) That class always strikes me as having high power-to-weight. It has methods like encloses(anotherRange), contains(aValue), and others. https://google.github.io/guava/releases/19.0/api/docs…
Could someone tell me the meaning of _ in this Swift code: func greet(_ name: String,_ day: String) -> String { return "Hello \(name), today is \(day)." } greet("Bob", "Tuesday") In me prior experience usually _ denoted an unused parameter/variable. Also: I find the string interpolation syntax ugly... The syntax choices in Swift are curious, but not the most aesthetical/practical in my opinion.
0..<count is a lovely little piece of language design
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...
Earlier quoted context omitted.
When 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.
Yes, 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.
0..<count is a lovely little piece of language design
Indeed a clear syntax. OTOH, a "loop .. for .. {upto, below} count" leaves less questions in a casual code review :)
scala> 1 to 3
scala.collection.immutable.Range.Inclusive = Range(1, 2, 3)
scala> 1 until 3
scala.collection.immutable.Range = Range(1, 2)
Earlier quoted context omitted.
An alternative approach is Guava's Range class: Range.closed(1,5) == [1,5] Range.open(1,5) == (1,5) Range.openClosed(1,5) == (1,5] Range.closedOpen(1,5) == [1,5) Range.greaterThan(1) == (1,infinity) Range.atLeast(1) == [1,infinity) That class always strikes me as having high power-to-weight. It has methods like encloses(anotherRange), contains(aValue), and others. https://google.github.io/guava/releases/19.0/api/docs…
Should the second "closed" be "closed Open" (with the corresponding change to the rest of the line)?
0..<count is a lovely little piece of language design
An alternative approach is Guava's Range class: Range.closed(1,5) == [1,5] Range.open(1,5) == (1,5) Range.openClosed(1,5) == (1,5] Range.closedOpen(1,5) == [1,5) Range.greaterThan(1) == (1,infinity) Range.atLeast(1) == [1,infinity) That class always strikes me as having high power-to-weight. It has methods like encloses(anotherRange), contains(aValue), and others. https://google.github.io/guava/releases/19.0/api/docs…
There does seem to be broad agreement across a range of typed languages -- TypeScript, Swift, Kotlin, ES6 + Flow -- about notations for classes, control flow and data structure declaration. But true convergence remains far away...
If true convergence happened, there wouldn't be a need for different languages. :-)
I like swift's conditionals without brackets, OTOH the syntax for string interpolation is ugly