Greetings All, Any thoughts on adding support for ...

# language-proposals

[ianbrandt]

Greetings All, Any thoughts on adding support for using the spread operator with `Iterable`'s? It would make it easy to create arrays and collections from them, e.g.:

val bowlingFrames = arrayOf(*1..10)

Also:

val notAnArray = listOf(1, 2, 3)
val list = asList(-1, 0, *notAnArray, 4)

(https://discuss.kotlinlang.org/t/arrays-from-ranges/5216)

Update: Looks like I'm late to the party with this one: https://youtrack.jetbrains.com/issue/KT-12663.

[Ruckus]

What would the resulting array be of

*(1.9..2.7)

[ianbrandt]

@Ruckus Good point. How about making the spread operator overloadable, and then just not overloading it for ClosedFloatingPointRange in the stdlib? If someone really wanted to provide an implementation for that, they could do so in an extension function.

[Ruckus]

It's not just ClosedFloatingPointRange. I can create any sort of range that isn't discrete in nature.

[ianbrandt]

Right, I was just thinking you'd overload spread() on Iterable instead.

[Ruckus]

I'm not a fan of overloading the spread operator. I don't see it as an operator for using in code, just as a vararg operator that removes Java's ambiguities. Kotlin is all about being explicit, and throwing in strange operators all over starts looking too "magic" for lack of a better term. That's why you can only override a small selection of predefined operators, and it's only recommended to do so where it makes unambiguous sense.

[Ruckus]

In general, I think the build in collection and array construction functions are a much better solution.

List(n) { ... }
IntArray(n) { ... }
...

They are explicit, unambiguous, and still quite concise,

[Ruckus]

(Not to mention overloading the spread operator and allowing it in normal code could cause ambiguities with the multiplication operator).

[ianbrandt]

Fair enough. How about enhancing the spread operator as it is to support arrays and iterables?

[Ruckus]

I'm not sure what the implications would be. You'd have to ask someone smarter 🙂

[ianbrandt]

We'll see if anyone else chimes in. Thanks for the critique! It definitely refined my thinking on this.

[Ruckus]

My pleasure. It's good to question basic assumptions from time to time to make sure they're still valid.

[eddie]

(Not to mention overloading the spread operator and allowing it in normal code could cause ambiguities with the multiplication operator).

Kotlin already has a unary - operator, though. And other languages utilize a unary *, like C & C++, for example.

[Ruckus]

Ah, fair point, though that was the most inconsequential of my claims (which is why it was in ()). I believe the rest of my arguments are still substantial.

[ilya.gorbunov]

What would the resulting array be of

arrayOf(*(1.9..2.7))
@Ruckus Floating point ranges are not iterable, so there's no problem with that, it won't just compile

[Ruckus]

Makes sense, though I think I still prefer the Array(n) { ... } style.

[Ruckus]

@ilya.gorbunov Would that entail an overloaded spread operator, or just special syntax for iterables?

[eddie]

I think an overloadable spread operator would be interesting, especially in the Kotlin/Native context as you could use it for pointer tricks

[eddie]

Y'all are no fun. 😉

[Ruckus]

In the immortal words of Crush

You've got serious thrill issues dude