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 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.
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.
Maybe it’s a bit clickbait, but yes, it hasn’t been communicated well! And context(_:IO) is just a shame!
@@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.