what about implicit parameters for multi-arguments...

# language-evolution

[elect]

what about implicit parameters for multi-arguments lambdas? ie: it0, it1,..

[Emil Kantis]

I think I would prefer first, second 🙂

[elect]

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

[Joffrey]

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

[Joffrey]

Do you have examples of code that would significantly benefit in readability from this shortcut?

[elect]

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

[Joffrey]

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

[elect]

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

[Joffrey]

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.

[elect]

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

[Roukanken]

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

[elect]

?

[elect]

I'm talking just about implicit naming schema

[elect]

@Ruckus why so much negativity 😄

[Roukanken]

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

[Roukanken]

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

[elect]

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

[ephemient]

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

[ephemient]

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

[elect]

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

[ephemient]

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)

[jimn]

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

[louiscad]

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.

[ephemient]

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