https://kotlinlang.org logo
#kotlin-native
Title
# kotlin-native
r

ribesg

10/04/2023, 9:16 AM
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
f

Florian Levis

10/04/2023, 9:20 AM
a shorter way is to add it globally to your project in gradle
Copy code
kotlin {
    sourceSets {
        all {
            languageSettings.optIn("kotlinx.cinterop.ExperimentalForeignApi")
        }
    }
}
👌 1
r

ribesg

10/04/2023, 9:28 AM
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 😅
c

CLOVIS

10/04/2023, 9:50 AM
^ 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
👌 1
2
f

Florian Levis

10/04/2023, 10:02 AM
thanks for the clarification @CLOVIS
r

ribesg

10/04/2023, 10:05 AM
Yes in my case it's an iOS app entirely in Kotlin
m

mbonnin

10/04/2023, 5:17 PM
@CLOVIS is it actually safe to use in libraries at all (even with propagation?). If the symbols change then linking will probably fail?
c

CLOVIS

10/04/2023, 5:18 PM
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?
m

mbonnin

10/04/2023, 5:19 PM
This is my understanding too. A K/N native executable only depends on the libc and maybe a few other .so
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?
But given that there are no backward compatibility guarantees on the klib format, this might be needed anyways.
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?
c

CLOVIS

10/04/2023, 5:31 PM
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
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)
m

mbonnin

10/04/2023, 5:31 PM
There's experimental backward compat but it's not a guarantee IIRC
There are still a few cases where it breaks there are a few YouTracks, let me dig
c

CLOVIS

10/04/2023, 5:33 PM
In any case, my advice is still sound, even if there are no promises made
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?
c

CLOVIS

10/04/2023, 5:46 PM
If it is, it's not documented in any obvious places
m

mbonnin

10/04/2023, 5:47 PM
Yea, don't think there is, it's a per-symbol thing...
Oh well, I "only" have 48 places 😄
c

CLOVIS

10/04/2023, 5:48 PM
I'm lucky, I only had ~5 in my logger implementation.
🙌 1
m

mbonnin

10/04/2023, 6:06 PM
Mmmm how do you opt-in/propagate from
commonMain
?
ExperimentalForeignApi
is only available in native (kdoc)
🤔 1
I guess I need to expect/actual ``ExperimentalForeignApi``
Nope 😞
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.
f

Florian Levis

10/12/2023, 4:52 PM
@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
c

CLOVIS

10/12/2023, 5:41 PM
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 :)
1
f

Florian Levis

10/12/2023, 5:47 PM
👌 so, like @mbonnin initial problem, when creating a library : you have to flag everywhere it's needed ; right?
c

CLOVIS

10/12/2023, 5:47 PM
Yes.
f

Florian Levis

10/12/2023, 5:48 PM
Roger. Thanks for the clarification.
c

CLOVIS

10/12/2023, 5:48 PM
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
(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)
17 Views