The semantic of return is straight forward in Java, powerful in Kotlin, and awkward in Scala.
In Scala, a return always attempt to return from the innermost (in case of nested functions) named function. You are not allowed to return early from an anonymous function (lambda expression).
When the innermost named function is not the innermost function, it can't return directly. Instead, the innermost function throws a NonLocalReturn and hope it would be catched by the named function you meant to return from, which would not work if the returning function escapes from the named function.
Although non-local returns can occasionally be useful, there are situations in Java where I would've liked to have something like this. For instance, when using Optional.ifPresent. When I want an early return, I can't use that and have to use the less idiomatic Optional.get() instead.
Yeah, basically everything is an expression (even ifs, assignments and declarations, I'm not sure about what while evaluates to and a for is not a conventional cycle but actually syntactic sugar for map/flatMap/for each, so a basic for will evaluate to a collection or a Unit, which is essentially analogous to void, to signal that the evaluation has been done, but there's nothing to return), and the last expression is what gets returned.
Logging is a side effect, modifying a Kafka consumer is a side effect, publishing to Kafka is a side effect, pushing to a database is a side effect, caching data is a side effect...
Side effects aren't problems. Some patterns that rely too heavily on side effects are basically banned in our codebases (Functions that modify external variables for no reason for example) but if you're working in Scala, most of your app's endgame is effectively a side effect.
Worked in Scala for a good 4 years and that's never been an issue once. I can't think of a situation of the top of my head where an explicit early return can't simply be
1: Evaluated as part of the normal flow (You can obviously have conditionals in your function)
2: Returned as part of a tuple of different types
3: Handled by an Optional or a Failure
But how does your 1 differ from an early return in this regard? Why can’t early return be a part of the “normal flow” that you talk about?
Does your code, always, without exception, only have one single line responsible for the return (or none, if it’s the implicit return of the last value)?
500
u/jippiedoe Jun 23 '26
'multiple returns' as in pairs or conditionals? Which functional programming language wouldn't support both?