` fun foo(): (suspend () -> Int) = { 5 }`
# coroutines
b
fun foo(): (suspend () -> Int) = { 5 }
👍 6
j
fun foo(): KSuspendFunction1<>
could also work.
Speaking of. I know they’re mostly equivalent, but I can’t decide between using KSuspendFunction or the receiver function shorthand above.
g
I use only lambda syntax for all functional type, including suspend, same way as for other cases instead of FunctionN interfaces
s
I prefer the lambda notation, not the KFunction, etc ones
Sometimes i use a typealias, but only if it has a particular well-defined meaning in the modeling of the app.
j
My problem with that is if anyone unused to this notation looks at the code it’s a little bit difficult to know what to search online for in order to understand what’s happening.
s
True. When folks learn Kotlin, or when you teach Kotlin, it is important to show how higher order functions work and how they look. It’s one of the first things to tackle.
j
I don’t like to go on the assumption that a developer underwent a full Kotlin course before touching my code. Especially not with the large amount of “if you can code Java you can code Kotlin” statements out there, which gives some people the impression that they don’t have to read up about everything.
s
That is why i think it is important to visit the topic of lambdas/higher-order functions rather sooner than later and consider it part of the ‘basics’. And Kotlin is a different language. Nothing wrong with learning new one, even it is just the basics 🙂
j
Definitely, but I’m not the one who needs to be convinced here. The issue is that I know for a fact people who know even less than me will work on my code in the future.
I know I can’t convince all of them to swot up before working with Kotlin, so I at least want to make it easy for them to google the thing they’re working with I suppose.
s
That is indeed something to consider. And that is why we at our company (we create apps for clients) carefully choose whether to use Java or Kotlin. But once the choice is made, we strive to write in the language as idiomatic as possible. In this example, it would mean to favor
() -> Any
over
KFunction1
for example 🙂
(and I must admit; I don’t like Kotlin code that looks like Java 🙂 ; it would be better to use Java instead)
j
🤔
Thanks for the feedback. I guess I should think of higher order functions as more core to what a typical programmer should know about a language.
👍 1
b
To me
KFunction1
is an implementation artifact of the lambda implementation. E.g. Haskell has no separate type/syntax for lambdas; I don't think Scala does, either (although I am less sure of this).
☝️ 2
And don't get me started on the disastrous requirement for
CheckedFunctionX
in Java 😄
😄 1
s
Yup. Lambdas and higher-order functions and extension functions are part of the core kotlin knowledge (and a few other things). But things such as coroutines, (property) delegates, etc are more advanced
z
Also I think that the
K*Function*
types are jvm-specific, so you can’t use them from common modules in multiplatform projects