Hello. Consider that example, where both usages o...

# getting-started

[Vlad]

Hello.

Consider that example, where both usages of highOrder() effectively do exactly the same:

object SomeClass {
    fun doSomething(id: Int) {}
}

fun highOrder(
    a: (something: Int) -> Unit
) {
    a(35)
}


fun main() {

    // Usage 1
    highOrder(
        // Passing Lambda expression (could be trailing)
        a = { something ->
            SomeClass.doSomething(id = something)
        }
    )

    // Usage 2
    highOrder(
        // Passing Method reference.
        a = SomeClass::doSomething
    )
}

Can we say that Usage 2 is lambda or it will be technically incorrect?
Will be there different output from the compiler for the usages? (I need to learn how to see the complier output 0\)

[Klitos Kyriacou]

No, usage 2 is not a lambda. In both usages, you're passing a function type parameter to your highOrder function. A lambda expression is one way to create such a function-type parameter, it's not a type itself, but just a syntax. Even though the Kotlin compiler (at least the current versions) produces different bytecodes for these two usages, they're equivalent and their performance is almost the same.

[ephemient]

the object constructed for a lambda expression { ... } is slightly different than the object constructed for a function reference ::, as the latter is also a KCallable with == and .name etc.

[ephemient]

if it were

inline fun highOrder(
    a: (something: Int) -> Unit
)

then the bytecode would be the same in both cases, as it skips creating the lambda object

[Vlad]

huh, I didn't even think about the inline.
Although the main topic of our in team evening discussion was if labmda or not (don't know why).

Whelp, I was right about the not lambda, and now I have an idea what will be under the hood.
Thank you.

[ephemient]

it's a KFunction either way and if you're imprecise enough to call it a lambda I think you'd still be understood