what about implicit parameters for multi-arguments lambdas? ie:

it0, it1,..

I think I would prefer

first, second

🙂

I'd prefer it (pun intended 😬) more compact, but I'd take that anyway over the current implementation

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

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

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

I'm always for teaching good practices rather than forbidding new features for a potential abuse

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.

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

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

?

talking about this issue: https://pl.kotl.in/zaZYqekl2

Got it, well, in case of signature matching then it could be required to explicitly naming the arguments

I don't think this should be added to the Kotlin language due to interaction with other features like overloading

I know, indeed I hate that (mandatory named parameters)

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)

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

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.

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