Abolishing Kotlin Context Receivers

[@kyay10]

TL;DR: context receivers and context parameters aren't really 2 separate features, but more so an evolution of a feature. Context parameters will end up fulfilling almost everything that we wanted from context receivers Haven't finished the video fully yet, but in terms of elegance, context parameters will actually be pretty alright. The only downside is that you'll have to make contextual "bridge" functions to members. Skipping a (minor) compiler version isn't so bad as well. I think the context receivers to context params hasn't been communicated well enough. My understanding is that the differences are very tiny, and in a way context params are just a natural evolution of context receivers (but with names, and without propagating member/extension functions, only context functions). The same core idea is still absolutely there, and the migration should actually be pretty simple once context params are out (just adding a name or _ for every context, creating bridge methods, and that's it) Oh and having contexts on classes is getting removed too, but that feature wasn't fleshed out fully anyway.

[@PairingWithDuncan]

Maybe it’s a bit clickbait, but yes, it hasn’t been communicated well! And context(_:IO) is just a shame!

[@kyay10]

@@PairingWithDuncan I don't even think your video is clickbait. There's been somewhat of a "panic" (for lack of a better word) in the context-using community, and it's unfortunate because the reality isn't that bad at all. `context(_: IO)` is annoying, but that's a minor change that can be easily added in the future. I think right now they don't want to add `context(IO)` because there's an idea to have different semantics for that (which would basically match the current CR semantics) but that idea hasn't been explored fully.

[@DanieleSegato]

​@@PairingWithDuncan TBH that IO's of yours is a bad practice in my opinion. You shouldn't, to use your words, "having to prove that you know the function is using IO" to call it. In fact, it would be better to not know how the function is implemented at all. Context parameters are meant to be used for when you need functionality out of the context. There's no functionality in the IO object, it is just a marker that forces the caller to know details that it shouldn't know about.

[@PairingWithDuncan]

Thanks for your feedback @DanieleSegato, but 'bad practice' is a bit strong? It was an experiment, introduced in Defining an IO Context in Kotlin (kzbin.info/www/bejne/omHQdJp-nauehpY), and the motivation was to try a low-friction way of differentiating pure from impure functions. I think that is a worthy goal, because we have to treat pure and impure functions very differently. I may not want to know _how_ a function is implemented, but I almost always do want to know if it is pure or not. I sort of had in mind contexts for IO, Random, and Time - the usual impure culprits, where IO is separate because it is (much more) subject to failure, and to work my way towards the Arrow context-receiver error handling for IO. Unfortunately the rescinding of context receivers has shot that down too, at least for now. For more thinking on pure and impure, see Master Functional Thinking - Actions, Calculations, Data (kzbin.info/www/bejne/i4C8YZSJpdyeqac) and Calculations to Actions (java-to-kotlin.dev/chapter_samples/chapter07-calculations-to-actions.html)