Alejandro Serrano

> My question is the following: why would an API author want to make its API inaccessible to Java? What would be the semantics of such an intention and what...

Following a suggestion from @qwwdfsad, I've added a [new section](https://github.com/Kotlin/KEEP/blob/jvm-expose-boxed/proposals/jvm-expose-boxed.md#explicit-api-mode) that mandates choosing whether you want to expose operations or not when using explicit API mode. That way library authors...

Re-reading this thread I think there was a bit of misunderstanding about how `@JvmExposeBoxed` is supposed to work. I've tried to clarify it in a [new section](https://github.com/Kotlin/KEEP/blob/jvm-expose-boxed/proposals/jvm-expose-boxed.md#the-jvmexposeboxed-annotation), that I would...

About the explicit API mode: this depends on the compiler version and may also depend on the language version. This annotation would only be mandated if you are compiling from...

Update: we have decided to prohibit `@JvmExposeBoxed` on abstract members for the time being, because we run into the [same issues that for `@JvmName`](https://youtrack.jetbrains.com/issue/KT-31420/Support-JvmName-on-interface-or-provide-other-interface-evolution-mechanism).

@daniel-rusu one (kind of implicit) change in the design is that now you always require opting in to the feature, either by annotation or by using a compiler flag. Since...

The experimental implementation of this feature shall appear in Kotlin 2.2.0. This PR will remain open for further feedback for a few weeks after the release.

@daniel-rusu sorry for taking too long to answer. > Would it be possible to update the KEEP to explain the handling of components with `internal` visibility? It doesn't seem that...

> Also, does arrow-match belong to arrow-optics if it doesn't depend on optics? I'm not really sure about where it should be. In my mind it goes in optics because...

Since context parameters will not poison the binary, maybe we should just include these functions in `arrow-core`? WDYT @nomisRev?