Can the internal FFIConverter* types be hidden?

[mgeisler]

Hi all,

I'm using UniFFI with mls-rs and it's working well. The results so far can be seen in mls-rs-uniffi.

When generating Kotlin bindings, I notice a lot of helper types being generated. A small part of the documentation looks like this right now:

Of these, Group is a type I exposed, the rest are part of the UniFFI scaffolding. There are a few more such types (RustBuffer*, NoPointer, Uniffi*, ...).

Would it be possible to move these types to a sub-package or perhaps they could simply be marked package private or similar? I don't know exactly what mechanism is best for Kotlin, but anything which hides the classes from the documentation would be nice.

The same would of course apply to other target languages. The question is thus if this has been discussed in the past and if people would be open for patches that implement some form of hiding?

[mhammond]

We recently saw mls because it aligns with work we are planning to do and was quite excited to see uniffi used there, then saw your name attached to it and it all made sense :)

In general, this sounds great. Some of these symbols probably do need to be "public" because they are referenced from other modules, but I'm fairly confident our test suite will cover all these cases - but they can probably be "hidden" (whatever that means for the specific binding in question). You mention sub-modules which might work well for some of the bindings - but yeah, we'd almost certainly take PRs for this.

[mgeisler]

We recently saw mls because it aligns with work we are planning to do and was quite excited to see uniffi used there, then saw your name attached to it and it all made sense :)

Nice! 😄 I'm excited too about this effort to bring more MLS to platforms like Android and iOS with the bindings created here!

In general, this sounds great. Some of these symbols probably do need to be "public" because they are referenced from other modules,

Yeah, I don't think we can avoid exposing some parent classes here and there. In Android, we will eventually make the library available via Android Jetpack, and I understand that we have certain API guidelines for this. I'm not sure exactly what this means and if it restricts us in what we can leave public in the generated API.

We have played with the idea of writing a shim API on top of the auto-generated API coming out of UniFFI — but it would of course be ideal to avoid this as much as possible to make maintenance reasonable.

You mention sub-modules which might work well for some of the bindings - but yeah, we'd almost certainly take PRs for this.

Excellent! Then I'll start investigating what is possible and send some PRs to update the output.