跪拜 Guibai
← All articles
Kotlin · Android

Kotlin 2.5.0-Beta2 Adds Experimental onTrue, onFalse, and ifOrNull to Simplify If-Else

By RockByte ·
Read original on juejin.cn ↗ Google Translate ↗ Alt translation

These helpers are a small but telling step in Kotlin's shift toward expression-oriented, chainable syntax. If they graduate from Beta, Android developers can shed the noise around simple condition checks without adding a dependency.

Summary

Kotlin 2.5.0-Beta2 ships three experimental standard library functions designed to cut down on hand-written if-else branching. onTrue() and onFalse() attach to a Boolean receiver, run a lambda only when the value matches, and hand back the original Boolean, which makes them fit for logging, analytics events, or other side effects without changing the flow. ifOrNull() takes a condition and a lambda, executes the lambda only when the condition is true, and returns its result; otherwise it returns null. That covers the common 'return a value if condition holds, else null' pattern that shows up in UI mapping and DTO construction.

The functions are still experimental in this Beta, so using them requires an explicit opt-in via @OptIn(ExperimentalStdlibApi::class) or the compiler flag -opt-in=kotlin.ExperimentalStdlibApi. The Kotlin team has already outlined them in the Beta1 release notes, but production teams should check the latest docs before relying on them, since experimental APIs can change or be dropped. The author's examples lean heavily on Android scenarios: authentication logging, profile phone-number fallback, and API response mapping all become a single chained call instead of a two-branch if-else.

Takeaways
— onTrue() and onFalse() are extension functions on Boolean that execute a lambda only when the value matches and return the original Boolean.
— ifOrNull() takes a Boolean condition and a lambda, returns the lambda's result when the condition is true, and null otherwise.
— All three functions are experimental in Kotlin 2.5.0-Beta2 and require @OptIn(ExperimentalStdlibApi::class) or the compiler flag -opt-in=kotlin.ExperimentalStdlibApi.
— The functions target side-effect logging, analytics, and conditional value mapping without needing an if-else block.
— The author notes they resemble Result's handling and sees them as part of a broader trend toward chained calls.
Conclusions

The onTrue/onFalse pair mirrors Result's onSuccess/onFailure API, which means developers who already work with Result will pick these up without a mental jump.

The author's observation about RxJava's popularity hints that Kotlin's user base has a genuine appetite for fluent, chained syntax, even if these particular functions are trivial; they could be precursors to more advanced control-flow abstractions.

Concepts & terms
ExperimentalStdlibApi
A Kotlin annotation that marks standard library APIs as experimental. Calling such APIs without @OptIn(ExperimentalStdlibApi::class) or the -opt-in compiler flag produces a warning, and the APIs are not guaranteed to stay stable across releases.
From the discussion
Featured comments
吭咔唑

You can just use extension functions to do that, the company project is still on 1.7.20.

RockByte

Of course, this isn't necessary either.

See top comments, translated →
Source: juejin.cn ↗ Google Translate ↗ Backup ↗