Is there any better way to get an array from a range?
(0..10).toList().toTypedArray()
Should the Of functions be overloaded to accept ranges?
@Test
fun testSort() {
val expected = arrayOf(0..10)
val actual = arrayOf(10 downTo 0)
sort(actual)
assertArrayEquals(expected, actual)
}
…seems a lot nicer than:
@Test
fun testSort() {
val expected = (0..10).toList().toTypedArray()
val actual = (10 downTo 0).toList().toTypedArray()
sort(actual)
assertArrayEquals(expected, actual)
}
I suppose one could want an Array<IntRange>, but that doesn’t seem like the majority use case to me.
I can’t think of a better way using extension functions though, in practice, I’d probably create an array using expressions such as the following rather than use ranges directly:
IntArray(11) { it } // ascending
IntArray(11) { 10 - it } // descending
Doesn’t seem that common to want it in the standard library. If it is something you need a lot extension methods like this would do the trick:
fun IntProgression.toArray() =
IntArray(this.count()).also { forEachIndexed { index, i -> it[index] = i } }
But this will not be as efficient as what @alanfo suggested.
In general I think Kotlin shies away from a lot of operations that result in arrays because arrays are expensive as you have to have all the data vs. a List which is just an interface and can be more lazy.
Another idea might be to support the spread operator for Iterable’s, which would save overloading all the collectionOf(...) and arrayOf(...) functions:
@Test
fun testSort() {
val expected = arrayOf(*0..10)
val actual = arrayOf(*(10 downTo 0))
sort(actual)
assertArrayEquals(expected, actual)
}
Yes, kotlin is actively developed. They release a new version every few months with patches in between. I’m not sure which bugs/posts/enhancements you mean when you say that none of them get implemented. You also have to consider that some enhancements just don’t get implemented because they don’t fully fit with what the designers want to do, eg more utility functions for arrays might not be something they want to add because kotlin’s design prefers lists over arrays. Other times it’s just an issue of prioritization.
Yes it is under active development. At this point, I suspect that if JetBrains were to stop working on it, others would take over take over development due to so many companies have stakes in Kotlin (some already doing bits of work in the Kotlin compiler).
This is a bit off topic so maybe it should be split into another topic? This question comes off as a troll post as Kotlin updates and new developments aren’t hard to find. Especially with the recent KotlinConf, roadmap, etc.
What do you mean by “none” of the issues are fixed? Have you seen the roadmap? It’s possible that the issues being fixed happen to be focused on use-cases that are higher priority for others and lower priority for you.
I will accept your comment and that one from @wasabi at face value - i.e development is active. I asked because I just noticed that any of the tickets/issues associated with this one were “open”. And IMO this is an issue that should be fixed early in the language development. I was concerned because I got into apache spark very early on - and although it’s a great technology the advancements slowed down tremendously in 2015 as the developers at DataBricks decided they had other priorities. I am a scala guy first and would like to change to Kotlin since the latter takes away some fussiness and seems to retain the vast majority of the power. But I am trying to understand whether that’s a prudent long term strategy. I will stick with scala a bit longer but have my eye on this.
Ah okay. Now I see you meant specifically the ticket linked in this thread.
Kotlin has a lot of momentum thanks to the large company support. At least JetBrains, Google, Atlassian, Spring, and others are willing to bet rather heavy in man-hours and future products on long term Kotlin usage.
In my opinion, OP’s issue of converting a range to an array, although leading to some interesting discussion, isn’t largely important to Kotlin’s maturity. The issue is uncommon and not too painful, and the issue currently can be worked around by libraries/extensions.
