03/09/2019, 4:11 AM
Some of the issues is "I want this function to be suspendable, but I don't to mark it suspend" -> Inline it so it will use whichever context it is in.


03/09/2019, 4:23 AM
That’s not how suspend works
If you don’t mark it suspend, it won’t suspend the coroutine it’s called from, regardless of whether it’s inline or not. The only difference is that making it inline takes away one function call


03/09/2019, 4:35 AM
It does work in the following fashin
(I don't want it to suspend, just to accept suspension)
suspend fun foo(other: suspend () -> Unit) { }

fun boo(func: () -> Unit) { }
I'm not able to do something like foo { boo { foo { } } }
When boo is inlined, the
will """""take"""" the context from the outside foo, and I'll be able to suspend anything inside it, due to the external
giving me the suspend context
Maybe I expressed myself wrong
My point is: Is it ok to always inline
, wherever it's possible? (Consider a big amount of functions similar to boo in the codebase I'm working with)
Or is it going to cause any kind of issues?


03/09/2019, 6:31 AM
I think it's worth trying to limit the number of calls to the block to 1 statement, as well as limiting the other code, for example by moving it to another function
Inlining too many things can have performance drawbacks because inlined functions cant be individually targeted by the jvm's JIT
Obviously if theres a code block, it will generally lead to better performance, especially if inlining avoids boxing primitives or inline classes.


03/09/2019, 6:39 AM
So if the IDE doesn't complain, perhaps it's ok? hahah
I'm not minding too much on performance. This is for testing code, and generally we're aiming for comfort to write > performance


03/09/2019, 9:08 AM
Inline with functions parameters is perfectly fine. Just try to extract big chunks of code that do not directly deal with lambdas to book inline functions for code reuse (and avoid counterproductive compiled code duplication).