https://kotlinlang.org logo
#language-evolution
Title
# language-evolution
e

elect

12/15/2021, 2:24 PM
what about implicit parameters for multi-arguments lambdas? ie:
it0, it1,..
10
🦜 2
e

Emil Kantis

12/15/2021, 2:25 PM
I think I would prefer
first, second
🙂
1
e

elect

12/15/2021, 2:27 PM
I'd prefer it (pun intended 😬) more compact, but I'd take that anyway over the current implementation
j

Joffrey

12/15/2021, 2:29 PM
This might add some convenience in some cases, but in most cases this would probably be considered bad practice and using named arguments would be encouraged instead. It gives me a weird feeling of being back to shell scripts and accessing command line arguments. Also, the name
it
is nice for a single argument because it reads like english:
map { it.toSomething() }
takeIf { it.isNotEmpty() }
Using
it0
,
it1
etc. would not be as nice
Do you have examples of code that would significantly benefit in readability from this shortcut?
e

elect

12/15/2021, 2:32 PM
https://gist.github.com/elect86/4960063397eeeed0c609573e08145fe7 no wait, wrong/too generic example functions calling this (spoiler, I need all the way to Vec4 and Mat4(x4))
🙏 1
j

Joffrey

12/15/2021, 2:39 PM
This use case of mathematics, and especially vectors is well suited for numbered arguments because those are coordinates. I agree for this specific use case that this would be beneficial. However, a lot of (most?) multi-arg lambdas out there don't have this property. Arguments can be of different nature and type, and numbering them doesn't make as much sense as it does here. So I'm not entirely convinced it would be that beneficial, but I can clearly imagine people reaching for it because they are too lazy to write proper names and it's shorter, even in cases where it actually hurts readability. Maybe that's not a sufficient argument against such feature, I don't know, but that's my opinion
e

elect

12/15/2021, 2:40 PM
I'm always for teaching good practices rather than forbidding new features for a potential abuse
j

Joffrey

12/15/2021, 2:49 PM
It's not only about this. Adding a new feature also adds maintenance cost and complexity to the language. So it needs to be worth quite a bit. And out of all the lambdas out there, I assume only a tiny fraction would benefit from such an addition (arguments of the same type, for which numbering makes sense, and with a body short enough to warrant shortening the arguments). Even for those, it's not so obvious to me that
{ x0, x1, x2 -> // use x0, x1, x2 }
is that terrible compared to
{ // use it0, it1, it3 }
. So I'm wondering whether it would be worth it. Misuse is just one part of the "cost" of that feature, and I agree it's not a sufficiently valid argument to rule something out.
e

elect

12/15/2021, 2:52 PM
Ok, right. But if you take a single line, it's not terrible. But if you scaling then it starts adding up and it's worth, at least for me
r

Roukanken

12/15/2021, 3:12 PM
also, this already happens, but it would introduce much more complex overload ambiguity - you would not be able to have function taking lambdas with different argument count
e

elect

12/15/2021, 5:01 PM
?
I'm talking just about implicit naming schema
@Ruckus why so much negativity 😄
r

Roukanken

12/15/2021, 5:04 PM
talking about this issue: https://pl.kotl.in/zaZYqekl2
no argument lambda's are not that common so it doesn't happen much but it is an odd overload case and not easily resolved extending implicit naming would exaggerate it much more
e

elect

12/15/2021, 5:10 PM
Got it, well, in case of signature matching then it could be required to explicitly naming the arguments
e

ephemient

12/15/2021, 7:06 PM
I don't think this should be added to the Kotlin language due to interaction with other features like overloading
it could be viable with a completely different set of language design choices: Swift has implicit
$0
,
$1
, etc. parameters in its closures, but it rarely has overloads by the same name, which is reinforced by requiring named parameters almost everywhere
e

elect

12/15/2021, 7:09 PM
I know, indeed I hate that (mandatory named parameters)
e

ephemient

12/15/2021, 7:11 PM
but because of that, they'd rarely have overload ambiguity on closure type, whereas overloading by lambda type is something that can naturally arise in Kotlin code without ambiguity (prior to your proposal)
j

jimn

12/17/2021, 10:34 PM
https://en.wikipedia.org/wiki/C_shell has
$0, $1
and has opened a lot of doors as a C-like shell. kotlin is like c-shell for java so we can just use ... wait...
l

louiscad

01/04/2022, 2:26 AM
I'm always for teaching good practices rather than forbidding new features for a potential abuse
That's probably how guns came to be, and came to not always be used for the right thing. This philosophy works for some people, but never works for everyone, mostly because many folks skip the learning phase, aka doc/feedback reading.
e

ephemient

01/04/2022, 2:44 AM
a professor (who was also a firearms instructor) once explained to me: "don't teach people what not to do, they'll fixate on it and end up doing it. instead, teach what to do" of course there's some more nuance than that in reality, but that's probably a similar concept
22 Views