How to protect against misplaced return?

Language Design
21

It is, but not into the body of the function where you’re making the call.

1 Like
22

By 3 everyone is “What the heck?”…

I can understand you here, I find it unusual too because a classic inline function transforms returns into assignments and does not inline the return into the host function.

What Kotlin does instead here is to treat inline lambdas as hygienic mixins pasting identifiers into the scope of the host function with some unique prefix before and keywords are directly pulled into the host scope.

23

I’m not sure who defines what a “classic inline function” is and even if there is a “classic” definition out there I think it is reasonable to allow languages to take a different aproach. The way inline functions work in kotlin is one of the core systems in kotlin. It’s not some hidden niche part of the language and it is not that complicated and can be explained in 2 sentences.
return returns from the nearest function denoted by the fun keyword. Lambdas are not functions (don’t use the fun keyword), but can be passed/assigned to function types.
This should be enough for everyone who has a basic understanding of higher order functions. If higher order functions are new, there is no excuse to not read the docs, which have an excelent explanation of how inline works in kotlin: https://kotlinlang.org/docs/reference/inline-functions.html

Kotlin had to make a decission here:

  1. Go the “classic” way
  2. Get to use all the amazing features non local returns provide

I personally prefer 2. It allows for scoping functions, nice builders and a lot of other features. Compare java having to add a new language feature for AutoClosable vs kotlin just adding an extension function to AutoClosable.

1 Like
24

Sorry to hear a coding bug cost your company $. You now have a great business case for justifying more time and money spent on CI, QA - and listening to engineers when they push back on crazy timelines.

All languages have a subtlety to the keywords / syntactic sugar. Code in a ‘simple’ language, like ‘C’, and understand how every keyword has (sometimes unintended) side-effects - then you learn to scrutinize them in high level languages like Kotlin :wink:

Your coders comment actually highlighted what is missing - exception handling and finally wrapper around lambda.
Using ‘inline’ is almost always wrong - in high level languages it is wrong - let the optimizing compiler do it’s job. And keep compiler optimizations out of business logic.

25

That’s not actually true for kotlin. There are 2 situations where inline is correct in kotlin.

  1. higher order functions (taking lambdas as arguments)
  2. reified types
2 Likes
26

I suspect the problem is that you are coming from a language like Javascript

Or Java. Or Python. Or Rust. Or C++. Or Go. Or Swift. Or D. Or any other language with lambdas: every one of them treats return in a lambda as return from the lambda. Except Kotlin. Great

Return is not explicitly disallowed in lambdas—it is allowed, it just does something different, which is sometimes (often!) what you want

No, I usually don’t want non-local returns, I need them once in a blue moon. But have to use return@blabla every time I need to return from lambda.

1 Like