Why is it

*

btw? Could be something more comprehensible like this 🤔

ByteString.of(vararg buffer.toByteArray())

the spread operator is a very common operator in many languages.

vararg

is a declaration site operator, whereas

*

is a use site operator.

"always been done like X" is not a strong argument though. Where are

&

,

|

and

^

operators? 😄

the same argument could be made for all operators in a language. why do we use

.

to make method calls. why not have everything be lisp. fewer operators means less confusion right?

See, it's not an argument for anything.

Having it be a common operator is a good argument. It means the likelihood of someone having used it and understanding it immediately is much higher.

Having a spread operator like

*

is rare. Using them is even rarer.

Having a spread operator like

*

is rare.

Using them is even rarer.

I don't know why you think this.

It does denote variadic parameters. It could also denote variadic arguments.

Groovy, Kotlin, Ruby, Javascript, PHP, Julia, TypeScript all have splat operators.

Python uses * so it was familiar to me when I started looking at Kotlin https://docs.python.org/3/tutorial/controlflow.html#unpacking-argument-lists

wtf is Julia and who uses Groovy. Ruby, PHP, Python ok - all popular

looks like ceylon also has the same spread operator.

Gradle being the only case for Groovy is not a lot and most code is

build.gradle

files where you rarely need anything except the basics.

Python and JavaScript go one further and let you unpack/spread maps too

Anyway, I'll move the idea & discussion to #language-proposals 🙂

The spread operator can be used multiple times for the same vararg parameter.

Gradle being the only case for Groovy is not a lot and most code is

build.gradle

files where you rarely need anything except the basics.

I feel like you haven't used gradle in an enterprise setting. I've written several thousand lines of groovy/kotlin just to support our release pipeline for our microservices. These are plugins that are used in the build.gradle files.

I write my release pipelines in build.gradle.kts files

I know - there's always a scenario of everything. I just don't believe that it's a significant portion of developers who come in touch with Groovy's spread operator.

Yeah I write all my gradle stuff in kotlin now as well, but there was a time there when you couldn't do certain things in kotlin which sucked.

For further discussion: https://kotlinlang.slack.com/archives/C0B9K7EP2/p1559230543003600

don't believe that it's a significant portion of developers who come in touch with Groovy's spread operator.

but combined over hundreds of languages (there are over 700 languages currently existing today), the spread operator is very common and immediately recognizable to a significant majority of those people.

*

is fine, people are used to it. Alas, Dart decided to follow JavaScript syntax `...`: https://github.com/dart-lang/language/issues/47#issuecomment-462326152

the spread operator is very common and immediately recognizable to a significant majority of those people.

700 languages don't really matter. Only about 25 of them have > 1% usage. What should matters is the percentage of developers actually using the spread operator.

No it doesn't matter, because it's not going to be changed. What is the point of this discussion? I think I missed it

This is a proposal and a discussion. There is no decision.

Well, make proposals for things that dont already exists, there is 0% chance that this will be changed

I'm afraid that ship has sailed

Removing things from the language which are potentially not needed can be as useful or even more useful than adding new things to a language.

You cant remove things from a language that guarantees backward and forward compatibility

Sure you can. Swift is a prime example for that.

Swift isn't Kotlin

I'm afraid that ship has sailed

@ghedeon why? It's a very easy code migration (a feature which Kotlin already offers), is binary compatible and can be changed over time with deprecation.

Again, I repeat what I said: You can use the spread operator multiple times for the same vararg parameter.

You're not going to convince anyone in this thread, and good luck with convincing the language designers. This is a standard feature in many many languages, and having it 'hidden' behind the

*

operator doesn't make it any harder than any other part of the language to use.

@snowe the feature remains exactly the same. Just the operator changes.

You could say the same about the

%

operator. why isn't is

modulo

as a keyword?

Swift is a good example of breaking compatibility? Not sure it's something to brag about). And they don't have spread operator yet. Speaking of PHP, spread operator is again

...

.

@snowe there's rem already if you're fancy:

1.rem(2)

why use

!!

when you could instead have the keyword

not

or just use

if (blah == null) throw Exception

@ghedeon imo it's a good thing that Swift is trying to focus on a good language more than on backward-compatibility for their earlier days at least. They've learned from the mistakes made during the evolution of PHP, JS, C++ and other languages.

I disagree that those are mistakes.

Yeah, we disagree here 🙂

In my opinion, maintaining back (and forward) compatibility is absolutely worth the risk of keeping not-so-great language features around. Judging from what I see and hear from our iOS teams when they need to deal with Swift upgrades…. a lot of grumbling from the iOS side 🙂

Kotlin is a strongly typed language which makes it possible to write automatic conversion of (most) code between language versions. As long as code can be migrated automatically changing things for the better (if they do - that's the crucial point) should be a no-brainer - at least for major language releases. Was it sometimes hassle to upgrade Swift versions? Yes. Was it worth it? Yes! A lot of the language and the standard library couldn't be as good as it is today wouldn't there be room for improvements. It's impossible to get everything right all the time, so in general the ability to change something is a good thing. It's also thinking in terms of trade-offs short-term (comfort) vs long-term (a rock-solid language).

I just feel like we are bikeshedding right now. vararg functions by themselves are already fairly uncommon. Passing an array into one? Even more rare. Is the spread operator kind of strange? Yes. Is this issue so serious that we should break backwards compatibility with every Kotlin codebase ever written to fix it? Obviously not. Also, the issue with different incompatible language versions isn't the difficult upgrade process. It's the documentation. If I see some python code I have no clue what version of python it's meant for unless it has a shebang line (which not always helps as it sometimes just points to

python

, not something like

python2

). I literally have to read through the source code or run the program to figure out. I've come across tons of gists that don't say the python version and this is definitely a huge problem even today. The same with Swift. It's super painful. The effects of a breaking language change are felt for a long time past the upgrade itself.

Could be something more comprehensible like this

Nobody will introduce a new feature yet alone a breaking change based on opinions with no good reasoning behind it.