https://kotlinlang.org logo
Join Slack
Powered by
Maybe not the best channel for this but it seems t...
# language-evolution
a
Maybe not the best channel for this but it seems that Kotlin 2.1.20 changed something wrt to context receivers compared to 2.1.10. We have some lambdas that accept two context receivers, and one extension receiver. It looks like this:
Copy code
title: context(Component.Slot<Text>, Component.Slot<Icon>) RowScope.() -> Unit

fun Component.Slot<Text>.Text(...) {}
In Kotlin 2.1.10 this worked fine:
Copy code
title = {
  Title()
}
But in 2.1.20 this is an error with:
Copy code
cannot be called in this context with an implicit receiver. Use an explicit receiver if necessary.
The issue is that you don't seem to be able to actually add a context receiver as there doesn't seem to be a way to access the context receiver.
c
context receivers are an experimental feature that has been removed in 2.1.20, to be replaced with context parameters in 2.2.0. https://youtrack.jetbrains.com/issue/KT-67119
a
Yeah I know that, but context receivers work fine otherwise in 2.1.20
🤷 1
Oh weird, it only seems to be an issue when using trailing lambdas
When using named parameters it works fine
I'm very surprised that it still works though
I suppose they didn't actually fully remove it
The warning did change:
Copy code
Kotlin compiler version 2.2 will be the last version that supports context receivers.
Consider migrating to extension receivers or regular parameters now.
Alternatively, migrate directly to context parameters when Kotlin 2.2 is released.
I'm really confused now, it sounds like 2.2 will support both context receivers and context parameters
c
indeed, confusing.
a
let me clarify a bit (although more info will come in the release notes of 2.2): we've decided to make 2.2 a "bridge release" in terms of contexts, so you can migrate your code easily from one style to the other (in fact, in IntelliJ you'll be able to apply most of those changes automatically) On the other hand, it may be that in some cases you "see the stitches" of this transitional period, and this is mostly in the cases of lambdas (so your case, unfortunately). Although the team is trying its best, the main goal is to have 100% support for context parameters, even if we break 5% of context receivers on the go (which they need to update, anyway) The recommendation here is to start migration now if you can, and it would be great if you could also report any problem you may have found along the way. Thanks for experimenting with the new features 😄 😄
a
Wait, so context parameters are available in 2.1.20?
a
it's half-there, but you can try with 
-Xcontext-parameters
a
Oh interesting
Can I read about the status of the implementation anywhere? Such as what is supported and what isn't?
a
unfortunately not; the feature is going to be in Beta (every piece implemented and run by our QA team) by 2.2.0, but we give no guarantees in 2.1.20
a
Gotcha, do you recommend not enabling it in production then?
I'll try it out and report any issues
a
the general recommendation is to wait until 2.2.0 (on top of the fact that context receivers were already experimental, so they are not recommended for production either)
a
We've been using context receivers for years without issues, so I'm assuming that context parameters are probably fine too
Should I file issues or wait until 2.2?
a
tbh, not sure 😕
a
Only issue I've seen so far is the same as my original issue; when using a trailing lambda you get an error with the implicit receiver
d
I ran into issues with context receivers with inline functions where the order of parameters got messed up by the compiler. I haven't played a lot with context parameters, but I did try them out briefly in the EAP and it seemed to work.
a
Yeah they seem to work great, only issue is that ktlint doesn't accept its formatting
😕 1
p
I seem to have encountered a similar issue (
cannot be called in this context with an implicit receiver. Use an explicit receiver if necessary.
) introduced in 2.1.20 in the cross-play of context-receivers (and context-parameters) with dslmarker - https://pl.kotl.in/SKLn3b26G Weirdly enough, introducing a type-argument on the scope function "fixes" it and it resolves properly.
a
the implementation in 2.1.20 is really experimental. The Team is currently fixing a lots of bugs that were raised for this and the Beta1, so by 2.2.0 the implementation will be much better
p
I expected as much - especially with supporting both context-receivers and context-parameters in a single version (it seems context-receivers is in some way now underpinned by context-parameters implementation from the errors I see) I know 2.2.0 is RC still but it too is affected with when a lambda with context and a @DslMarker-annotated receiver now refuses to resolve the receiver implicitly. Without the @DslMarker it works correctly, and without the context, but both together it requires an explicit resolver (which impacts the utility of the DSL)
a
may you provide a code snippet and expected behavior, so I can create an issue about this?
p
This is probably the simplest reproducer I can think of for this play link: https://pl.kotl.in/evQPCIhMo compiles on 2.0.21 but no longer compiles on 2.1.20 or 2.2.0-RC (https://pl.kotl.in/eEFB2shQa) in both cases, removing the dsl marker annotation will work
Untitled.cpp
a
The runtime stability has been great for us!
17 Views
Open in Slack
PreviousNext
Powered by