Why are stdlib helpers like the scope functions (`let`, `run`, `apply`, `also`, `with`) and `repeat` declared `inline`, and what does that buy you?

## What `inline` means Marking a function `inline` tells the compiler to **substitute the function body — and the bodies of its lambda arguments — directly at each call site** instead of making a real call. For higher-order functions this is the key optimization, because normally each lambda becomes an object implementing a `FunctionN` interface, and calling it is a virtual `invoke()`. ## Why the stdlib uses it for scope functions `let`, `run`, `with`, `apply`, `also`, plus `repeat`, `use`, `takeIf`, `takeUnless`, and `runCatching` all take lambdas and are tiny. Making them `inline` means: - **No allocation**: the lambda isn't turned into an object — zero GC pressure for `list.forEach { ... }`-style code. - **No call overhead**: the body is pasted in; there's no `invoke()` dispatch. - **Zero-cost abstraction**: `x?.let { it.foo() }` is as efficient as a hand-written null check + call. ```kotlin val r = repeat(3) { println(it) } // body inlined, no Function object created ``` ## Non-local returns Because an inline lambda's body is part of the caller, a plain `return` inside it returns from the **enclosing** function: ```kotlin fun find(list: List<Int>): Int? { list.forEach { if (it > 0) return it } // returns from find, not just the lambda return null } ``` This only works because `forEach` is inline. ## Modifiers on inline lambda parameters - **`noinline`**: keep this particular lambda as a real object — needed when you must store it, return it, or pass it to a non-inline function. - **`crossinline`**: the lambda is still inlined but **non-local returns are forbidden**, required when the lambda is invoked from a different execution context (e.g. inside another lambda/object). - **`reified`**: an inline function may mark a type parameter `reified`, so `T` is known at runtime; this powers `filterIsInstance<T>()`, `instanceOf`-style checks, and `inline fun <reified T> Gson.fromJson(...)`. ## Trade-offs - Inlining **duplicates bytecode** at every call site → larger code size if the function is big or called in many places. Hence inline is for **small** helpers. - The compiler warns when `inline` provides no benefit (e.g. a function with no lambda parameters and no reified type) — it's mostly useful for lambda-taking or reified functions. ## Why it fits the 'stdlib model' theme This is the unifying idea behind much of the stdlib: rather than baking control constructs into the language, Kotlin ships them as **inline higher-order functions** that compile away, so library code reads like syntax but costs like handwritten code (`use` ≈ try-with-resources, `repeat` ≈ a for loop, scope functions ≈ explicit blocks).