context receivers will be removed in 2.1.20, so a ...

# getting-started

[Norbi]

> context receivers will be removed in 2.1.20, so a minor version, and then context params will be added in 2.2.0
Removing a complete language feature in a minor version does not sound right for me.
Why not remove context receivers only in 2.2.0 when context parameters are already added? Wouldn't it be more logical? Why is it necessary to have a "transition period" when none of them are supported?

Additionally, these "minor versions" typically contain lots of bug fixes, and it is often problematic to skip those versions.
In practice I'm usually sitting on pins and needles waiting for the minor releases fixing important compiler/other errors.

I still think that this "migration plan" is awful, not practical at all, it's like coming from a theorist 😕
Sorry, but I'm really sad/angry because of this 😞

[Oliver.O]

Why is it necessary to have a "transition period" when none of them are supported?

As stated in the above YT issue:

Note that this part is most likely inevitable as the implementation of context parameters requires quite extensive refactoring in the compiler, and there are significant chances that we won't have either context receivers or context parameters at that time.

[There is a slight chance that we'll have an early prototype of context parameters, but we are not counting on that.]"

Given this description in the original announcement of Kotlin 1.6.20-M1 (emphasis mine):

Please note that the implementation is a prototype:

• With -Xcontext-receivers enabled, the compiler will produce pre-release binaries that cannot be used in production code.

• The IDE support for context receivers is now minimal.

Try the feature in your toy projects and share your thoughts and experience with us in this YouTrack issue.

Experimentation means trying something out and learning from it. The result may be that the design changes or a feature is dropped completely. This may happen at any time, because making stability guarantees for an experiment would defeat the whole purpose.

[Norbi]

Thanks for the answer.
I know what an experimental feature is.
But this:

requires quite extensive refactoring in the compiler

does not mean that it would be impossible to provide a practical migration path for those who have really devoted time to try out the feature, report bugs, and experiment with it using non-trivial, non-dummy, non-helloworld-level code.
It does not explain for me at all why it is necessary to release an intermediate version without any of the two features.
I feel it as a non-practical decision from someone who is very removed from everyday software development.
Especially because this feature has been part of the language since multiple major versions.

Of course I can do nothing, I will have to adapt somehow.
And of course I will never invest serious time and resources into trying out experimental features in the future, even if they will have been part of the language for a long time.

[ephemient]

this isn't a "removed from software development" decision. somebody who actually works on the compiler has determined that the process of implementing context parameters will almost certainly break context receivers as they're in the same part of the compiler. the work will start but probably not be done within a single release, so you have at least one release without either.

[Norbi]

I am sorry if I hurt anyone's feelings.

But I feel that noone wants to understand my arguments. (Maybe my English is poor, I'm very sorry, it is not my native language.)

certainly break context receivers

I don't say that I don't understand that "implementing context parameters will almost certainly break context receivers as they're in the same part of the compiler".
I'm sure that these two are conflicting features, and it is a major work to implement these.
My only problem is: why release the intermediate version?

The current plan means the following release schedule:
1. release x: has context receivers
2. release y: context receivers removed
3. release z: context parameters added
Why not consider the following, i.e. not releasing the intermediate version:
1. release x: has context receivers
2. <not released>: context receivers removed
3. release y: context parameters added
But as I see that probably nobody else sees this a problem, so I will stop whining and get back to work.
Sorry for wasting your time.

[Youssef Shoaib [MOD]]

That was well communicated, thanks for clearing that up!
I think the simplest answer is that Kotlin has a fast release cycle, and because of the need for quick bug fixes, etc, they need to release minor versions very frequently. Some of those minor versions thus won't have either context receivers nor parameters.
However, according to their plan, this won't affect any major versions!
They need to make minor releases, and somehow working simultaneously on multiple versions of the compiler with/without contexts would likely be too difficult and for barely any benefit.
I think it's good to clarify that you likely won't be forced to upgrade to a minor version, and so you can simply ignore that minor version.

[ephemient]

if it were possible to implement in a single release, that would be nice. but they've scheduled in anticipation of that not being possible.