https://kotlinlang.org logo
Title
m

Marc Knaup

05/30/2019, 3:06 PM
Why is it
*
btw? Could be something more comprehensible like this 🤔
ByteString.of(vararg buffer.toByteArray())
s

snowe

05/30/2019, 3:14 PM
the spread operator is a very common operator in many languages.
vararg
is a declaration site operator, whereas
*
is a use site operator.
m

Marc Knaup

05/30/2019, 3:16 PM
"always been done like X" is not a strong argument though. Where are
&
,
|
and
^
operators? 😄
You see the confusion when people first encounter it. That confusion could be reduced.
s

snowe

05/30/2019, 3:18 PM
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?
m

Marc Knaup

05/30/2019, 3:18 PM
See, it's not an argument for anything.
s

snowe

05/30/2019, 3:19 PM
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.
m

Marc Knaup

05/30/2019, 3:20 PM
Having a spread operator like
*
is rare. Using them is even rarer.
Kotlin is supposed to be easy for everyone, not just people coming from other languages.
s

snowe

05/30/2019, 3:21 PM
Having a spread operator like
*
is rare.
Using them is even rarer.
I don't know why you think this.
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.
it doesn't do what vararg does. it does the opposite.
m

Marc Knaup

05/30/2019, 3:23 PM
It does denote variadic parameters. It could also denote variadic arguments.
Java - where many Kotlin developers come from - doesn't have a spread operator. Nor does Swift. Nor C++.
s

snowe

05/30/2019, 3:24 PM
Groovy, Kotlin, Ruby, Javascript, PHP, Julia, TypeScript all have splat operators.
1
kotlin probably took it's splat from groovy and ruby.
oh python as well.
j

Jonathan Mew

05/30/2019, 3:25 PM
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
m

Marc Knaup

05/30/2019, 3:26 PM
wtf is Julia and who uses Groovy. Ruby, PHP, Python ok - all popular
JS/TS are quite unique as their spread operations involve much much more than just varargs
s

snowe

05/30/2019, 3:26 PM
looks like ceylon also has the same spread operator.
anyone that is touching gradle uses groovy by default so quite an enormous amount of people use groovy.
m

Marc Knaup

05/30/2019, 3:29 PM
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.
j

Jonathan Mew

05/30/2019, 3:29 PM
Python and JavaScript go one further and let you unpack/spread maps too
m

Marc Knaup

05/30/2019, 3:30 PM
Anyway, I'll move the idea & discussion to #language-proposals 🙂
d

Dico

05/30/2019, 3:31 PM
The spread operator can be used multiple times for the same vararg parameter.
s

snowe

05/30/2019, 3:31 PM
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.
💯 2
👆 3
d

Dico

05/30/2019, 3:32 PM
I write my release pipelines in build.gradle.kts files
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.
m

Marc Knaup

05/30/2019, 3:35 PM
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.
And you don't need Groovy for Gradle anymore. Fortuntely tbh.
s

snowe

05/30/2019, 3:35 PM
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.
m

Marc Knaup

05/30/2019, 3:36 PM
s

snowe

05/30/2019, 3:36 PM
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.
g

ghedeon

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

Marc Knaup

05/30/2019, 3:41 PM
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.
d

Dico

05/30/2019, 3:42 PM
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
m

Marc Knaup

05/30/2019, 3:43 PM
This is a proposal and a discussion. There is no decision.
d

Dico

05/30/2019, 3:43 PM
Well, make proposals for things that dont already exists, there is 0% chance that this will be changed
g

ghedeon

05/30/2019, 3:44 PM
I'm afraid that ship has sailed
m

Marc Knaup

05/30/2019, 3:44 PM
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.
Try PHP as a language which almost only adds things 🙂
d

Dico

05/30/2019, 3:45 PM
You cant remove things from a language that guarantees backward and forward compatibility
m

Marc Knaup

05/30/2019, 3:45 PM
Sure you can. Swift is a prime example for that.
d

Dico

05/30/2019, 3:45 PM
Swift isn't Kotlin
There are no good grounds to change this
m

Marc Knaup

05/30/2019, 3:45 PM
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.
d

Dico

05/30/2019, 3:46 PM
Again, I repeat what I said: You can use the spread operator multiple times for the same vararg parameter.
s

snowe

05/30/2019, 3:46 PM
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.
m

Marc Knaup

05/30/2019, 3:47 PM
@snowe the feature remains exactly the same. Just the operator changes.
s

snowe

05/30/2019, 3:47 PM
You could say the same about the
%
operator. why isn't is
modulo
as a keyword?
g

ghedeon

05/30/2019, 3:47 PM
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
...
.
m

Marc Knaup

05/30/2019, 3:48 PM
@snowe there's rem already if you're fancy:
1.rem(2)
s

snowe

05/30/2019, 3:48 PM
why use
!!
when you could instead have the keyword
not
or just use
if (blah == null) throw Exception
m

Marc Knaup

05/30/2019, 3:52 PM
@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.
d

Dico

05/30/2019, 4:16 PM
I disagree that those are mistakes.
I'm happy that we can still compile and use code written tens of years ago
m

Marc Knaup

05/30/2019, 4:22 PM
Yeah, we disagree here 🙂
s

streetsofboston

05/30/2019, 4:56 PM
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 🙂
m

Marc Knaup

05/30/2019, 5:04 PM
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).
n

nulldev

05/30/2019, 5:19 PM
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.
☝️🏽 4
p

Paulius Ruminas

05/30/2019, 6:02 PM
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.