Anyone else adding `@file:OptIn(ExperimentalForeignApi::class)` to hundreds of files because of <htt...

# kotlin-native

[ribesg]

Anyone else adding @file:OptIn(ExperimentalForeignApi::class) to hundreds of files because of https://kotlinlang.org/docs/whatsnew19.html#explicit-c-interoperability-stability-guarantees ?
Fun times

[Florian Levis]

a shorter way is to add it globally to your project in gradle

[Florian Levis]

kotlin {
    sourceSets {
        all {
            languageSettings.optIn("kotlinx.cinterop.ExperimentalForeignApi")
        }
    }
}

[ribesg]

My initial goal was to add the annotations and then slowly go through them and properly encapsulate those calls, as suggested by the change, without realizing that I had thousands of such calls in 264 files… Thanks for that, I'll use that instead 😅

[CLOVIS]

^ the tips above are fine if you are making an application, but if you're making library, do not opt-in at the module-level, in fact, do not opt-in at all. Instead, propagate the warning to your users, otherwise their projects will break whenever this gets changed

[Florian Levis]

thanks for the clarification @CLOVIS

[ribesg]

Yes in my case it's an iOS app entirely in Kotlin

[mbonnin]

@CLOVIS is it actually safe to use in libraries at all (even with propagation?). If the symbols change then linking will probably fail?

[CLOVIS]

If you update the Kotlin standard library without recompiling your app, sure, but I'm not aware of any distro that actually ships the standard library as a system library. To my knowledge, all native apps ship their own version of the standard library, so you're guaranteed they match, right?

[mbonnin]

This is my understanding too. A K/N native executable only depends on the libc and maybe a few other .so

[mbonnin]

But then whether you opt-in or propagate the warning, compiling the app will break. The moment the consumer updates to K2 (or whatver version breaks the cinterop), the app won't compile again and the lib will need to make a new version?

[mbonnin]

But given that there are no backward compatibility guarantees on the klib format, this might be needed anyways.

[mbonnin]

tldr; the whole K/N ecosystem is pretty much unstable so propagating the warning to consumer gives a small additional heads up but consumer should be prepared to update anyways?

[CLOVIS]

I think klib is stable enough that you can use libraries that were built with other Kotlin versions? So that means a library must be able to run with another standard library version than it was compiled with

[CLOVIS]

I have little experience with K/N but I don't remember having to explicitly match Kotlin versions with my dependencies (though maybe I was just lucky)

[mbonnin]

There's experimental backward compat but it's not a guarantee IIRC

[mbonnin]

There are still a few cases where it breaks there are a few YouTracks, let me dig

[CLOVIS]

In any case, my advice is still sound, even if there are no promises made

[mbonnin]

https://youtrack.jetbrains.com/issue/KT-52600/Stabilize-klib-make-binary-compatibility-easier-for-library-authors
https://youtrack.jetbrains.com/issue/KT-58568/Inconsistent-klib-dependencies-provided-from-gradle-to-the-JS-Native-compiler

[mbonnin]

In any case, my advice is still sound, even if there are no promises made

I guess so. But it's a pain for the lib author. Is it possible to propagate at the module level instead of each and every symbol?

[CLOVIS]

If it is, it's not documented in any obvious places

[mbonnin]

Yea, don't think there is, it's a per-symbol thing...

[mbonnin]

Oh well, I "only" have 48 places 😄

[CLOVIS]

I'm lucky, I only had ~5 in my logger implementation.

[mbonnin]

The fun never stops 😄

[mbonnin]

Mmmm how do you opt-in/propagate from commonMain ? ExperimentalForeignApi is only available in native (kdoc)

[mbonnin]

I guess I need to expect/actual ``ExperimentalForeignApi``

[mbonnin]

Nope 😞

[mbonnin]

I guess the root problem is that through propagation hoops I end up with @ExperimentalForeignApi symbols in expect declarations, which is called out as something not to do. Nevermind, that was the UnsafeNumber problem, not this one... oh well, time to call it a day.

[mbonnin]

I filed https://youtrack.jetbrains.com/issue/KT-62322/common-declaration-for-ExperimentalForeignApi

[Florian Levis]

@mbonnin @CLOVIS I have a "stupid" question...

Mmmm how do you opt-in/propagate from commonMain ? ExperimentalForeignApi is only available in native (kdoc)

but if you're making library, do not opt-in at the module-level, in fact, do not opt-in at all. Instead, propagate the warning to your users, otherwise their projects will break whenever this gets changed

How to you propagate an opt-in at all? Not specifically in native mode.

I've generated a http client based on an openapidoc with https://openapi-generator.tech/docs/generators/kotlin, option serializationLibrary=kotlinx_serialization, and updated configfile to kotlin kts.

I didn't OptIn "module wide" as said.

Compilation now emit warning like this:

This declaration needs opt-in. Its usage should be marked with '@kotlinx.serialization.ExperimentalSerializationApi' or '@OptIn(kotlinx.serialization.ExperimentalSerializationApi::class)'

When I use the library in a project, there is no warning about it 🤔
So what I understand is the optin is not propagated...

The documentation talk about "custom" annotation https://kotlinlang.org/docs/opt-in-requirements.html#propagating-opt-in

I'm lost :x

[CLOVIS]

You're calling a function which is marked as experimental by the @ExperimentalSerializationApi annotation.

If you want to propagate the experimental warning to your caller, just annotate your function with @ExperimentalSerializationApi as well, this way they get the same warning :)

[Florian Levis]

👌 so, like @mbonnin initial problem, when creating a library : you have to flag everywhere it's needed ; right?

[CLOVIS]

Yes.

[Florian Levis]

Roger. Thanks for the clarification.

[CLOVIS]

I agree it's not convenient, but it's very important for backwards-compatibility.

You can ALT-ENTER of the warning in IDEA and use the “propagate” action directly, it makes it somewhat easier

[CLOVIS]

(well, backwards-compatibility for Kotlin libraries in general. As said earlier in the thread, it's not actually enough to guarantee backwards-compatibility in Native, but it's still a good first step)