A modern programming language that makes developers happier.

kotlinlang

Is Swift Code Bundling a suitable tool to reduce "over-exporting" APIs from Kotlin to Swift?
An example in the thread

On the Kotlin side I have an umbrella `:shared` module. One of its indirect (transitive) dependencies `:feature:foo` has code like this:
```@JvmInline
@ObjCName("ClassId", exact = true)
interface ClassId {
    val value: String
    companion object {
        fun from(value: String): ClassId = ClassIdImpl(value)
    }
}

private data class ClassIdImpl(override val value: String) : ClassId```

I want to be able to use `ClassIdCompanion.shared.fom(value: "Blah")` on the Swift side.

In order to do this, I am forced to add these lines in the build.gradle.kts of `:shared` module
```export(projects.feature.foo)
// Also, instead of implementation, I need to use an api dependency
api(projects.feature.foo)```

Obviously this ends up exporting way more symbols to Swift than required (I get the gorilla and the entire jungle with it while all I wanted was the banana).

My question is: Is Swift Code Bundling a suitable tool to solve this problem?
If I create a refined API for the Swift side and place it alongside my ClassId Kotlin file, can I get rid of the `export` and replace my `api` with an `implementation` dependency?

```extension ClassId {
    static func from(_ value: String) -&gt; ClassId {
        return ClassIdCompanion.shared.from(value: value)
    }
}```

Alternatively, can I place my Swift file in the umbrella `:shared` module instead? Will that remove the need for the `export` and the `api` dependency? (since that's the module where I apply the SKIE plugin)

Okay I did a quick experiment and what I found is that if I remove the `export` from my build.gradle.kts then the Swift files in the shared sourceSet do not compile.

Although certainly not "elegant", to solve this specific case, I'd add a function in your umbrella ios source set that simply calls the underlying code:

```fun classIdFactory(value: String): ClassId = ClassId.from(value)```
Not pretty, but that'll solve your problem.

We've internally discussed a "precise" export capability. Some way to specify exports that aren't in the API Surface, without exporting whole modules, but it's something that never quite got enough interest to explore. Mechanical solutions like the one above aren't "pretty", but they are simple and practical.

Ooh why didn't I think of that. This solution is good enough for me.
It is also a nice way to place all such exports in one place.

This is not unheard of in other ecosystems like Dart, JS/TS.

Yeah, that was why the "precise export" never got beyond conceptual. We could do it, or we could just...