apologies if this has already been asked a million...

# arrow

[Fred Friis]

apologies if this has already been asked a million times but searching it doesn't look like it has 🙃 is there a rough idea of when arrow 2.0 will come out?

[CLOVIS]

When context receivers are binary-stable (most likely Kotlin 2.1 or 2.2).

To answer your next question: Arrow 1.2 stable is: whenever they have the time to get to it, there are no major blockers for it.

[simon.vergauwen]

When context receivers are binary-stable (most likely Kotlin 2.1 or 2.2).

Uhm, that is not accurate 🤔 We were thinking when K2 is released at the end of this year. Within the K2 series there should be no binary unstable changes within Kotlin. We think that we can make the switch to context receivers in a binary compat way.

I am hoping to release 1.2.0 soon.

[CLOVIS]

Oh, sorry for the incorrect message then. So you're saying Arrow will be able to use context receivers with forwards binary compatibility for whenever they actually become a stable feature? If so, that's great.

[simon.vergauwen]

Yes, I think so. There are several options, in some cases the signature might remain the same since i.e. context(A) () -> B will be the same JVM signature as A.() -> B.

APIs with multiple receivers will be new, so they won't be backwards breaking.

Only thing that would be breaking is Raise<None> for option, or Raise<Nothing?> for nullable, but in those cases it can be done in a binary compat way through a simple deprecation cycle. So that's probably a minor bump, not a major one. And the deprecations would be so simply, it can easily be done with ReplaceWith. (Only adding imports since it would be source compatible).

[CLOVIS]

That's good to know, I thought we had to wait for them to be stable to be sure of these things.

[simon.vergauwen]

Afaik context(A) () -> B can only be transformed into (A) -> B on the JVM, I thought that was pretty set in stone 😅 Perhaps suspend context(A) () -> B can be (A, Continuation) -> Any? or (Continuation, A) -> Any? so there it might actually differ 🤔

In such cases we can always leverage DeprecationLevel.HIDDEN since it would be source-compatible, and then it would remain binary compatible as well. DeprecationLevel.HIDDEN is one of my favorite compatibility tricks in Kotlin, as long as you stay source compatible you can just replace an entire implementation in a backwards compatible way.

[CLOVIS]

Oh, I completely forgot about HIDDEN. Indeed, it completely bypasses any problem we could have from this. I guess there's a downside of having to specify another @JvmName but that's a very small price to pay

[CLOVIS]

Well, all of this is great news 🙂

[simon.vergauwen]

I am also not sure if I've always had to use @JvmName 🤔

[CLOVIS]

Oh you're right: either it's the same signature, and no tricks are needed, or it's a different signature and @JvmName is not needed