Thread
#language-evolution
    e

    elect

    9 months ago
    what about implicit parameters for multi-arguments lambdas? ie:
    it0, it1,..
    Emil Kantis

    Emil Kantis

    9 months ago
    I think I would prefer
    first, second
    🙂
    e

    elect

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

    Joffrey

    9 months ago
    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

    9 months ago
    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))
    j

    Joffrey

    9 months ago
    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

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

    Joffrey

    9 months ago
    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

    9 months ago
    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

    9 months ago
    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

    9 months ago
    ?
    I'm talking just about implicit naming schema
    @Ruckus why so much negativity 😄
    r

    Roukanken

    9 months ago
    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

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

    ephemient

    9 months ago
    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

    9 months ago
    I know, indeed I hate that (mandatory named parameters)
    e

    ephemient

    9 months ago
    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

    9 months ago
    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

    louiscad

    8 months ago
    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

    8 months ago
    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