Update on Context Parameters

Context parameters are an upcoming feature in Kotlin, with a variety of use cases including more powerful extension methods and better tools for DSL development. Kotlin 2.2.0 will feature context parameters in Beta, and dedicated IntelliJ IDEA support will be available from 2025.1. Context parameters replace another experimental feature in the language, namely context receivers. […]

Apr 10, 2025 - 17:37
 0
Update on Context Parameters

Context parameters are an upcoming feature in Kotlin, with a variety of use cases including more powerful extension methods and better tools for DSL development. Kotlin 2.2.0 will feature context parameters in Beta, and dedicated IntelliJ IDEA support will be available from 2025.1.

Context parameters replace another experimental feature in the language, namely context receivers. Although always behind a feature flag, context receivers have been part of Kotlin since version 1.6.20, and are used in a non-trivial amount of code. This blog post describes our plans for the transition between both features.

Smooth transition

In Kotlin version 2.2.0 context parameters are released as Beta, but context receivers are not yet removed. To assist with the migration, when the context parameter feature flag is enabled, the context receiver syntax is still recognized as much as possible, and the compiler and the IDE hint for possible further actions. Migration is strongly recommended, as we plan to remove context receivers around the 2.3 release. Migration does not need to happen all at once: context receivers and parameters may coexist in your project (although within each single module at most one of them may be enabled).

If your project already used context receivers, you can get started by changing your free compiler argument from -Xcontext-receivers to -Xcontext-parameters. Upon re-syncing the project, new inspections appear wherever context receivers are used.

The main difference between context receivers and parameters is that the latter require a name. Introducing this name also requires prefixing any calls which were implicitly using the context receiver with a reference to this new name. In IntelliJ IDEA, starting from version 2025.1, this can be done using the provided Replace context receivers with context parameters quick-fix.

If in the same message you instead click on More actions… and then press the three vertical dots next to the name of the quick-fix, you can apply it to all the context receivers in the same file. IntelliJ IDEA will change all the occurrences of context receivers, introducing a name based on the type and the usage of the parameter.

You may even perform a module-wide or project-wide migration by going to Code | Analyze Code | Run Inspection by Name… and then executing Migrate from context receivers to context parameters or Outdated context receivers used (depending on the IntelliJ IDEA version). You can then choose the desired scope for the change.

Manual migration

Callable references to functions with context parameters are not supported in Kotlin 2.2.0. Implementation in the compiler requires some additional work that will be finalized for 2.3. We think that even without this feature, developers will get a lot of mileage out of context parameters. If you were using callable references to functions with context receivers, you can replace them with lambdas in most cases.

Context receivers in classes have no direct counterpart in context parameters (the KEEP document describes the reasoning behind this change). Depending on the particular use case, the migration path is quite different, so manual migration is required. We strongly recommend refactoring context receivers in classes now in preparation for the upcoming deprecation.

Conclusion

Context parameters are becoming a reality in Kotlin 2.2.0. For the brave, partial support for context parameters is already available in Kotlin 2.1.20. However, migration actions from IntelliJ are not available for that version of Kotlin, since the implementation is still in the experimental phase.

We recognize the need for a good migration path from context receivers into the new context parameter world. The Kotlin compiler and IDE teams are devoting part of their efforts to make this migration as smooth as possible.