Is there any way to distinguish these two? ```fun ...

# announcements

[Animesh Sahu]

Is there any way to distinguish these two?

fun test(a: () -> Unit) { println("A") }

fun test(a: suspend () -> Unit) { println("B") }

suspend fun main() {
    test {}
}

According to the language i.e. if kotlin - allow suspend lambda whereas call from non-kotlin like java/js - allow normal lambda 👀

[Animesh Sahu]

Ohk, so I was able to do so in this way:

test(suspend {
    ...
})

And the first function (takes nothing) should be able to be called from Java/JS (without continuation parameter).

My next question, is there a way to distinguish them without suspend function call on the stdlib? Like being able to put the trailing lambda outside parenthesis?

[Animesh Sahu]

Also it says overload resolution ambiguity without suspend (in trailing lambda manner) so neither first nor second can be called without explicitly calling suspend() and qualifying the lambda explicitly suspensive.

[Youssef Shoaib [MOD]]

If both of them have the same logic, by the way, then you can just use inline fun test(a : () -> Unit) and if it's called in a suspending context in Kotlin then you'll be able to call suspend functions in there too.

[Animesh Sahu]

@Youssef Shoaib [MOD] how would it be available from Js/Java then 🤔

[Animesh Sahu]

inlining it is not an option, I need an instance of lambda to store.

[Youssef Shoaib [MOD]]

It would be available normally but yeah if you need the lambda then sadly that wouldn't work

[Youssef Shoaib [MOD]]

hmmmmm well you can maybe do something like this:

@JvmName("test") 
fun testJvm(a: () -> Unit) { println("A") }

fun test(a: suspend () -> Unit) { println("B") }

suspend fun main() {
    test {}
}

[Animesh Sahu]

It wouldn't be available, as its inline and not present anywhere in the bytecode

[Youssef Shoaib [MOD]]

an inline function is still present in byte code

[Youssef Shoaib [MOD]]

and you can call it from java and js normally but in your usecase you need to store the lambda so an inline function won't work

[Animesh Sahu]

🤔

[Animesh Sahu]

Any reference?

[Animesh Sahu]

In my experiments I guess they weren't

[Youssef Shoaib [MOD]]

try the JvmName trick and see if it works or not

[Youssef Shoaib [MOD]]

the only type of inline function that doesn't exist in bytecode is ones that take reified type parameters but lemme find a reference in the docs real quick

[Animesh Sahu]

Oh nice! that's actually available, so that means, that inlining only decreases the runtime overhead of stack-calls (or lambda creation), and not the actual size of the bytecode. Also does it imply the lambdas are actually runtime-objects from the Java/JS calls-site?

[Youssef Shoaib [MOD]]

Yes if called from Java or JS you'll have to create actual lambda objects. inlining can improve the size of bytecode if you never call the inline function from a non-Kotlin context and so if you have any sort of code minifier (like R8) it should notice that the function is never actually called in bytecode and remove it automatically.

[Youssef Shoaib [MOD]]

This is a side tangent, so stop reading ahead if this doesn't interest you lol, but inline functions tbh are currently missing a lot of their potential power because of certain optimisations that aren't there. Take KT-44530 for example, if this is implemented, the inlining capabilities of Kotlin can be used to, with a bit of boilerplate, simulate "struct" types with basically no overhead and a very nice call site.