uniffi-rs
uniffi-rs copied to clipboard
Design and agree on a 1.0 FFI
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.