Why is it `*` btw? Could be something more compreh...

# announcements

[Marc Knaup]

Why is it * btw?
Could be something more comprehensible like this 🤔

ByteString.of(vararg buffer.toByteArray())

[snowe]

the spread operator is a very common operator in many languages. vararg is a declaration site operator, whereas * is a use site operator.

[Marc Knaup]

"always been done like X" is not a strong argument though.
Where are &, | and ^ operators? 😄

[Marc Knaup]

You see the confusion when people first encounter it. That confusion could be reduced.

[snowe]

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?

[Marc Knaup]

See, it's not an argument for anything.

[snowe]

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.

[Marc Knaup]

Having a spread operator like * is rare.
Using them is even rarer.

[Marc Knaup]

Kotlin is supposed to be easy for everyone, not just people coming from other languages.

[snowe]

Having a spread operator like * is rare.

Using them is even rarer.

I don't know why you think this.

[snowe]

Kotlin is supposed to be easy for everyone, not just people coming from other languages.

that's a good point, but I don't see how vararg helps that.

[snowe]

it doesn't do what vararg does. it does the opposite.

[Marc Knaup]

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

[Marc Knaup]

Java - where many Kotlin developers come from - doesn't have a spread operator.
Nor does Swift.
Nor C++.

[snowe]

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

[snowe]

kotlin probably took it's splat from groovy and ruby.

[snowe]

oh python as well.

[Jonathan Mew]

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

[Marc Knaup]

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

[Marc Knaup]

JS/TS are quite unique as their spread operations involve much much more than just varargs

[snowe]

looks like ceylon also has the same spread operator.

[snowe]

anyone that is touching gradle uses groovy by default so quite an enormous amount of people use groovy.

[Marc Knaup]

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.

[Jonathan Mew]

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

[Marc Knaup]

Anyway, I'll move the idea & discussion to #C0B9K7EP2 🙂

[Dico]

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

[snowe]

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.

[Dico]

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

[Dico]

Java doesn't have a spread operator, but Java is not a language to take too many ideas from, and it should have a spread operator.

[Marc Knaup]

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.

[Marc Knaup]

And you don't need Groovy for Gradle anymore. Fortuntely tbh.

[snowe]

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.

[Marc Knaup]

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

[snowe]

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.

[ghedeon]

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

[Marc Knaup]

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.

[Dico]

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

[Marc Knaup]

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

[Dico]

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

[ghedeon]

I'm afraid that ship has sailed

[Marc Knaup]

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.

[Marc Knaup]

Try PHP as a language which almost only adds things 🙂

[Dico]

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

[Marc Knaup]

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

[Dico]

Swift isn't Kotlin

[Dico]

There are no good grounds to change this

[Marc Knaup]

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.

[Dico]

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

[snowe]

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.

[Marc Knaup]

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

[snowe]

You could say the same about the % operator. why isn't is modulo as a keyword?

[ghedeon]

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 ....

[Marc Knaup]

@snowe there's rem already if you're fancy: 1.rem(2)

[snowe]

why use !! when you could instead have the keyword not or just use if (blah == null) throw Exception

[Marc Knaup]

@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.

[Dico]

I disagree that those are mistakes.

[Dico]

I'm happy that we can still compile and use code written tens of years ago

[Marc Knaup]

Yeah, we disagree here 🙂

[streetsofboston]

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 🙂

[Marc Knaup]

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).

[nulldev]

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.

[Paulius Ruminas]

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.