Haha. True. I was looking for more complicated return types like

Deferred<MutableList<SomeClass>>

my rule is to never omit return types for public funs

Yea. There is that possibility. Which can be enforced by code styles for instance. But I like that the syntax is lenient

I like it too, but for public funs there are consequences

Also, I can write a

fun a() = b

and do a quickfix to apply the type. Forcing me to put the type beforehand in return forces me to think too deeply about it

Even in Java you can make your function

public void a() { return someObject; }

and use the quickfix to change the return to the proper type. So I don't think that'd be an issue

Well. In Kotlin, both versions will be syntactically correct. But of course, not a big issue. Just pointing it out 😉