Enable experimental K2

[serras]

This way we track the experimental flag as part of the update to 1.9.0

Note: the build is set to 1.9.30-dev-1098 because of this bug

[nomisRev]

@raulraja I think you still have some automations attached to your account 😅

[serras]

@arrow-kt/maintainers I've turned this PR in one we can merge now, and keep checking K2 compatibility as we make changes with the added jvmTestK2. Right now the K2 part is checked against a dev version of 1.9.20, which should just be updated to the regular one as soon as the first public beta of that version is released.

[serras]

You may noticed there's a removal in arrow-optics. Those are functions which in my experience nobody call, since you need a very convoluted construction (since it's a method with receiver inside a class). Note that the removed method is not the every we use to create a traversal in a collection, since that's defined in the dsl package.

[raulraja]

@raulraja I think you still have some automations attached to your account 😅

Not sure how that happened or where it comes from but definitely not on purpose 😅

[JavierSegoviaCordoba]

@serras wouldn't this block any Arrow final release until Kotlin 1.9.10 and Kotlin 1.9.20 were released?

[serras]

@serras wouldn't this block any Arrow final release until Kotlin 1.9.10 and Kotlin 1.9.20 were released?

No, with the latest change in the workflow file the only action which is executed with 1.9.20-dev version of Kotlin is jvmTestK2. The rest still use 1.9.0, so the release can still happen as usual.

[serras]

@raulraja could we move forward and merge this? This would give us updated stats for K2 compatibility, while keeping the whole build and releases in the more stable K1.

[serras]

The problem for requiring @PublishedApi internal for annotations is still present as of 1.9.30-dev and it's marked as having 2.0-M1 as target.

[i-walker]

Thanks @serras !

[nomisRev]

You may noticed there's a removal in arrow-optics. Those are functions which in my experience nobody call, since you need a very convoluted construction (since it's a method with receiver inside a class). Note that the removed method is not the every we use to create a traversal in a collection, since that's defined in the dsl package.

@serras this is a binary breaking changes in 1.x.x. Was this necessary for K2, or is it something we can easily postpone to 2.x.x?

[serras]

this is a binary breaking changes in 1.x.x. Was this necessary for K2, or is it something we can easily postpone to 2.x.x?

Indeed, this is a binary breaking change, so we could postpone it. Also, I haven't checked whether it now works in a newer version of K2, which may be the case.

In 2.x the optics hierarchy has been pruned and cleaned, so this problem doesn't exist anymore.

[nomisRev]

Okay, I'm going to check on that. Do you know if there is a possibility we can automatically fetch latest Kotlin dev version on CI? 🤔 It's probably non-trivial, right?

[serras]

Okay, I'm going to check on that. Do you know if there is a possibility we can automatically fetch latest Kotlin dev version on CI? 🤔 It's probably non-trivial, right?

It's fairly doable: you can go to https://maven.pkg.jetbrains.space/kotlin/p/kotlin/bootstrap/org/jetbrains/kotlin/kotlin-compiler/maven-metadata.xml and read .metadata.versioning.latest using something like xq.

[nomisRev]

We're still on the latest dev version then, and it's failing. Is there a YouTrack ticket for this, or should we try to create a minimal reproducible first? Or is there some documentation that this kind-of encoding going to be deprecated in K2? 🤔

It seems related to context pollution, but not sure why this would be prohibited.
I agree that it's probably not used often, and requires a strange call-site but I think we should prevent the binary breaking change.

[serras]

We're still on the latest dev version then, and it's failing. Is there a YouTrack ticket for this, or should we try to create a minimal reproducible first? Or is there some documentation that this kind-of encoding going to be deprecated in K2? 🤔

It seems related to context pollution, but not sure why this would be prohibited. I agree that it's probably not used often, and requires a strange call-site but I think we should prevent the binary breaking change.

I would say just to bring it back, so we avoid the binary breaking change. As I mentioned above, that code is gone in 2.0, so it should not be a problem in the near future.

I didn't report this one in YouTrack, since it felt right to me somehow (as opposed to the "using a constant in an annotation is now considered public usage"). But we could do that too.

[nomisRev]

since it felt right to me somehow

🤔 Are we talking about the same thing? The issue I found was that if you define an extension function inside of a class. You can not refer to the class instance anymore. I.e.

class MyClass {
  fun String.doSomething() {
    val x: String = this
    val xx: String = this@doSomething
    val y: MyClass = this@MyClass //invalid doesn't compile.
    ...
  }
}

That is weird to me, but perhaps I am overlooking something 😅 Since this doesn't "work-around" doesn't work.

fun interface PTraversal<S, T, A, B> : PSetter<S, T, A, B> {
  private val self: PTraversal<S, T, A, B>
    get() = this

  public val <U, V> PTraversal<U, V, S, T>.every: PTraversal<U, V, A, B>
    get() = this@every.compose(self)
}