Hello,
Are there any proposals currently lying around to make return keyword optional? I would like to subscribe if there are any.
return still remains a huge pain and a source of numerous bugs for us. It is plain weird that it is optional in lambdas but not in top-level functions.
Thanks!
The return keyword already is optional for functions* in Kotlin.
A source of bugs? Thatâs surprising since using explicit returns is one of the major things recommend for languages like Groovy (where return is optional everywhere) to prevent bugs.
The reason itâs optional for lambdas is for the use case of short lambdasâitâs practicality for quick actions out waighs the cons of the increased chance of bugs from leaving it out.
For functions, the short use case is well covered by the expression form:
fun getGreeting(): String = "hello world"
fun triple(n: Int) = n * 3
fun prize(place: Int) = where(place) {
1 -> "gold"
2 -> "silver"
3 -> "bronze"
else -> "none"
}
fun pickPet(allergies: Boolean): Animal = if (allergies) Fish() else Dog()
Longer functions with block bodies make the cost of adding an explicit return small and the benefits of having it high.
You can see this decision in play when you have long lambdas or nested lambdasâwhere a developer can increase the clearity by explicitly returning from a lambda and possibly adding a label.
If thereâs a lot of use cases for block body functions where optional returns can provide some benefit then there might be a case. IMHO I suspect there arenât any use cases that are not already well covered by the expression function form.
The inconsistency is actually the source of distress and bugs.
In our experience, developers donât know where to put return. Consider this (option 1):
fun foo(...) {
// large block
bar {
// large block
return baz
}
}
versus (option 2):
fun foo(...) {
// large block
return bar {
// large block
baz
}
}
Which is extremely common in Kotlin. We found that developers will put return randomly between these two options. So hereâs a common pitfall:
bar but forgets crossinline.foo which uses bar and places return as in the option 2.This easily creates a bug and wastes thousands of dollars and precious human lives are lost.
The dilemma doesnât exist if return is always required (JavaScript):
fun foo(...) {
// large block
return bar {
// large block
return baz
}
}
Here they have to pace return at both points. Or, if return is completely optional (ideal Kotlin):
fun foo(...) {
// large block
bar {
// large block
baz
}
}
So, inconsistency itself is a huge problem.
Let me point out another example of distress:
fun foo(...) {
// large block
return baz
}
So far so good. But letâs wrap it up with bar (again, extremely common in Kotlin):
fun foo(...) = bar {
// large block
baz
}
So now it is required to make a change to remove return on a completely unrelated line! This messes up blame big time. If again bar is removed, which is often, then the developer has to go back and see where they need to add return.
I donât see how any âclarityâ is achieved by adding this 6 character word when its place is always at the last expression. Or, isnât in case of a lambda.
This change would be completely backward compatible since we would only make return optional. If you prefer to use it, fine, and this can be achieved with IDE (âinspectionsâ).
In our experience, developers donât know where to put
return. Consider this(code)This easily creates a bug and wastes thousands of dollars and precious human lives are lost.
Could you clarify this further? The two code snippets are functionally the same, both of them will return baz. What exactly is the bug here?
The dilemma doesnât exist if
returnis always required (JavaScript)
JavaScript behaves exactly like Kotlin in this regard. âstandardâ functions require an explicit return, arrow functions (x => x + 1) return the last (and only) statement implicitly. You might wish to choose another language to motivate your argument.
Let me point out another example of distress
(code)
A valid point, although in my own experience youâll find that most of these scenarios involve wrapping the code in an inline function, where the return statement is equally valid.
This actually goes to show that even experienced developers like yourself are easily fooled. Consider if bar is implemented like:
inline fun<T> bar(block: () -> T): T {
val result = block()
println("Closing important resources")
return result
}
Then in option 1 important resources are not closed. They are absolutely not the same! Here is a full example:
inline fun <T> bar(block: () -> T): T {
val result = block()
println("Closing important resources")
return result
}
@Test
fun testFoo() {
foo()
}
fun foo(): Int {
bar {
return 10
}
}
return here is a top-level return, not return from a lambda. How confusing!
Only single expression functions do not need return in JavaScript, all others need it. In Kotlin, the situation is quite different.
As the example shows, it is absolutely not valid. Itâs a recipe for disaster.
When I teach Kotlin in my company, I spend hours explaining how return works in Kotlin, and everyone is baffled.
There is no other language with such an ominous semantics.
I think the problems youâre discovering with returns are better solved by explicitly marking returns everywhere or taking a second look at the reference page on returns
Making returns optional everywhere would allow for more confusing code as a developer would go from having two options to threeâthe solution to incorrectly choosing what/when to return is not hiding the return.
I donât see how you spend hours explaining return in kotlin. return will always return from the nearest fun.
Also Iâd argue that your implementation of bar is wrong. The block lambda should have been marked with the crossinline keyword. Maybe there is an argument to be made that crossinline should have been the default and instead there should have been a keyword to allow for non local returns but itâs a bit late to change that. Maybe that could be changed with an optional compiler flag.
Explicitly marking every return would open a whole new can of worms. What if a developer forgets to mark it with @xyz? What if they marked it with a wrong @xyz? Can this really be enforced or caught during code review? How?
Now we have gone from return having a single meaning (albeit inconsistent from a developer perspective) to âone can return from any lambda to any lambdaâ situation. Not to mention that lambdas are not unique (you can have run inside a run inside a run â which run will return return?).
Pointing to a reference page is not very helpful. I understand how it works. I am pointing to a problem that we are seeing in practice where how it works creates bugs and headaches, and even proposing a backwards compatible solution.
Itâs like arguing that comparing null, undefined, false and 0 in JavaScript can be confusing, and a smart guy just points us to a reference page. Thanks but youâre not adding value to the discussion.
I explicitly said in my original post that developer A forgot to add crossinline, so youâre pointing to the obvious here. How many Kotlin developers would think that option 1 and 2 are the same? And isnât that a problem?
I agree with Wasabi here, the problem doesnât seem to originate from return but the default behaviour of inline functions. Making returns optional does not fix situations where people would want a early return from a lambda:
fun foo(...) : Code {
//opens stream and closes it at the end of the function, not made crossinline by accident
return bar { it: InpustStream
//code
if(condition) return Code.Error //BUG! stream won't close
//code
Code.Okay //okay, bar finished normally
}
}
I know. What I wanted to say is that return isnât the real problem here. crossinline is. Your suggestion to change return looks to me like a bandaid over a different problem, without affecting the underlying cause. Sry, if I didnât express that properly.
Kotlinâs non local return is a powerful feature that allows inline functions to behave as if they are language constructs. Removing return statements or non local returns from the language would break more than it would fix.
Resource clean up should be in a finally block (ideally you can just leverage use) . Even with crossinline there, the definition appears flawed since an exception would result in a resource leak.
Unexpected non local return seems like itâd only cause an issue if you are writing code that is already incorrect and broken for cases involving exceptions.
Wow, yes, that is real confusing to a non Kotlin guru (obviously like myselfâŠ)
Without seeing your implementation (and testing it for myself) I would not have followed that logic flow⊠I can definitely see how this could get confusing (referring to the example with println(âClosing important resourcesâ).
Thanks for bringing this up⊠better hit the reference manualâŠ
Is there any scope for an optional compiler warning at least? E.g. This is non local return, are you sure you want it⊠or consider marking this param as crossinline�
Itâs already an error to return from a crossinline lambda. Hereâs the screenshot from IntelliJ, notice how it suggests fixing it by explicitly returning to the lambda with return@bar2
@ccfnz as you learn Kotlin, watch how many times a return confusion comes up in practice. I bet most of the confusion points will be solved with explicitly marked returns.
If weâre talking about the specific println(âClosing important resourcesâ) example youâll see I placed that code in a finally block as chipays mentions. Without it, a caller can easily orphan the resource regardless of return behavior is the following:
// ...
bar {
error("Some error...")
// ...
return // notice it doesn't matter if bar accidentally early returns or not.
}
As @Wasabi375 explains, returns arenât too complicated. We return to the nearest function unless otherwise specified (see the reference page for runnable examples). Unlabeled returns always behave this way and the only way to get a different behavior is by using a labelled return.
The reason itâs not confusing is that the behavior is consistent. Every unlabeled return is the same and you never have to confuse it with a local return.
I guess that is the key, needing to know (or needing to remember) that you need (or at least should consider) crossinline on the block parameterâŠ
Also take your point in the example that closing/clearing resources is best in try finally block.
Yup.
I can see the desire to lock the returns into one behavior and use some special marker for local returnsâI imagine without that it would be confusing. Iâm glad it works that way already especially with a compiler error to force stop you from writing confusing returns.
For beginners learning Kotlin, you could just never mention local returns so that they donât have to worry about it. Theyâll use returns the way they expect from whatever language they came from.
Eventually they may see a label on a return and you could explain itâs a nice way to be explicit inside a lambda that theyâre used to implicitly returning the last line.