How should I enable context receivers in a KMP project? I tried: ``` targets.all { compilations...

# language-evolution

[Youssef Shoaib [MOD]]

How should I enable context receivers in a KMP project? I tried:

targets.all {
    compilations.all {
      compilerOptions.options.freeCompilerArgs.add("-Xcontext-receivers")
    }
  }

but that doesn't seem to work. I want to have contextual declarations in commonMain. I know that context receivers aren't implemented yet for non-jvm sources. Does that mean I'd have to make a jvmShared sourceSet so that I can have contextual code there?

[dmitriy.novozhilov]

Context receivers are supported only in jvm backend, so you can't use them in common source sets

[Casey Brooks]

It’s probably not worth trying to do anything with Context Receivers yet, since it’s been dropped from the roadmap until some yet-to-be-determined time after Kotlin 2.0 (with new K2 compiler) is released. There’s a lot of rough edges with them, and you’re not going to get any official support for them for a while.

Best to just ignore this feature for now until the Kotlin team announces that it’s back in development

[Youssef Shoaib [MOD]]

@dmitriy.novozhilov Could I at least have a jvm-only sourceset that's shared between desktop and android? So that I can have contextual declarations that are shared amongst them

[Javier]

I don’t think they were dropped, they were planned to be released
after K2 from long time ago, the roadmap when 2.0 is released will be interesting

[Casey Brooks]

They weren’t entirely dropped, but they have been de-prioritized and are not currently on the Roadmap. This doesn’t mean that they feature is being abandoned, or even that the work that’s been done so far will be removed, but it does mean that the Kotlin team is not actively working on this feature right now and they’re not committing to a time when they will pick it back up.

We know it won’t be in 2.0, and we shouldn’t hold out for it being in any specific release after that. At a minimum, given a roughly 6-month release cadence between minor versions, it could be a year or more until this feature is in a state where we could reasonably start using it in our projects.

[dmitriy.novozhilov]

@Youssef Shoaib [MOD] it should work
But I can't tell how it should be expressed in gradle config

[Youssef Shoaib [MOD]]

I figured it out. Ended up using the targetHierarchy experimental API, setting a group for desktop + android, and I enabled context receivers not using the compiler option, but using languageOptions.enableLanguageFeature("ContextReceivers") on all source sets, and that seemed to do the trick. Sadly, the language feature for context receivers doesn't seem to be documented anywhere at all. It would be nice if that was documented, because it seems like the compiler options way only works for targets, not for shared source sets, while enableLanguageFeature works for source sets

[dmitriy.novozhilov]

cc @tapchicoma

[tapchicoma]

but that doesn't seem to work

Do you mean in IDEA context receivers was not working?

[Youssef Shoaib [MOD]]

And when compiling. Seemed like freeCompilerArgs didn't apply for that shared JVM source-set

[Youssef Shoaib [MOD]]

My hunch is that it's because freeCompilerArgs is for compilation, but I'm not sure. Still, enableLanguageFeature worked flawlessly in IDE and compiler

[tapchicoma]

yeah, known issue. Should be fixed in 1.9.20-Beta. Also following DSL is planed to be available:

kotlin {
    compilerOptions {
         // common compiler arguments applied to all targets and shared source sets
   }
}

[tapchicoma]

for now - please use languageSettings in MPP projects until 1.9.20 release

[Youssef Shoaib [MOD]]

Oh beautiful! I figured it was weird that compiler args didn't take effect. It'd be nice, btw, if there was something in the docs listing all LanguageFeatures. I had to dig around in compiler sources till I found the enum for it to make sure that ContextReceivers really was a valid option

[Youssef Shoaib [MOD]]

Even just a comment for enableLanguageFeature listing some of them would be nice

[tapchicoma]

we don't want users to use LanguageFeatures directly, but some compiler argument instead (-X...). Also there is plan to expose such experimental compiler arguments in compilerOptions DSL as well

[Youssef Shoaib [MOD]]

Oh, weird. I seem to recall reading somewhere that `LanguageFeature`s was the more "correct" way. A nice compilerOptions DSL would definitely be the best solution here; I wanna just have an easy enable(ContextReceivers) call or something, so I don't have to think about strings or go hunting around for the right one

[tapchicoma]

that is the plan to have auto-completion in compiler options DSL so you don't need to hunt how compiler arg looks like 🙂

For now we are concentrating on stable compiler options - last bits should be done in 2.0 release

[Youssef Shoaib [MOD]]

Can't wait for the post-2.0 Utopia! Kotlin is gonna get so much better, something I thought was impossible