Design and agree on a 1.0 FFI

[bendk]

Lately, we've been discussing the idea of UniFFI 1.0 and what it would entail. As part of this effort, we should think about how we could improve on our current FFI layer. There's basically 2 reasons for this:

• Historically, UniFFI has favored shipping features quickly over performance, with the idea that we can revisit these decisions and improve on them later. This seems like a great time to revisit some of those decisions and improve upon them.
• We have a lot of hindsight around implementing bindings generators which we can use to simplify things. This will make our current bindings generation code more maintainable and make it easier for new bindings to be written.

General framework for making these decisions:

• This issue will be act as a meta issue for this work and track decisions around the overall direction. Please add your thoughts in the comments and we can update the plan as we go.
• The goal is get all stakeholders to come to a consensus on an FFI that's "good enough". This includes UniFFI users, UniFFI devs, bindings authors, developers of the ecosystems that UniFFI is being introduced into, etc.
• Issues for specific tasks will be labeled with FFI-1.0.
• There's no rush to get this done and we should expect that some of these issues will require slow and steady discussion before we can come to consensus.
• Changes should be justified based on improved performance, simplified binding generation code, or both.
• If a change is claimed to improve performance, there should be a benchmark added that measures this.

[bendk]

As mentioned in the description, this issue is a working document. The above represents my understanding of the issue after talking it over with a couple other UniFFI devs. If you disagree with anything or feel like something's missing, please add a comment.

[skeet70]

I agree that performance is something that should be optimized more before 1.0. Once we have a uniffi-bindgen-java version of our library that already exists natively in Java, we'll be benchmarking ourselves and may come up with ideas for improvements. Right now we have Rust, Python, and Kotlin benchmarks for that library but don't have a good comparison point to find improvements there.

Naively it seems to me like 1.0 should have either one of proc-macros or UDL but not both. I think that will simplify usage and make it easier to come up with a cohesive set of documentation.

Even though I'm implementing Java bindings, that's primarily translating Kotlin bindings, so I don't grok the bindgen internals well enough to give good improvement feedback there. I do think there's a lot to be gained in good documentation of what templates/code types need to be implemented and handled for bindings to support each feature UniFFI supports, but that's not really a maintenance improvement.