logo

Announcing `stabby`: a stable ABI for Rust with niche optimizations and much more!

430 points Fox-PhD
View on Reddit ↗

Hi Rustaceans!

After working on this project for about a month, I'm making the first announcement for stabby, a stable ABI for Rust as a library that supports niche optimizations in enums, dyn traits across the FFI, and much more incoming!

I'm currently in the process of writing a proper blog post about it, and a presentation for RustConf 2023, so I'll be short with this post, but feel free to ask any question! Here's a quick recap:

  • Rust's ABI is well known for not being stable, and it's been a pain-point for many plugin systems because that means a lot of the nice things we have in Rust can't be used without some C-ABI glue in the middle, which is tiresome to write.
  • The C-ABI (#[repr(C)] and extern "C") exists, which is very useful. However, that means enums have to become fat because niche optimization isn't a thing in #[repr(C)]
  • abi_stable is a decent solution, but a few aspects didn't suit me: the lack of support for closures and futures being the main one. The fact that enums would still become fatter being the second one.
  • stabby, however, abuses the turing-completeness of the trait solver completely, allowing it to represent enums as a tagged-union, but where the tag may be a ZST that defines how to interract with the union to use niches inside it.
    • The tag is constructed through a deterministic chain of type resolutions, which guarantees that it's stable across versions of the compiler.
    • The resulting tagged-union loses pattern matching :(
    • pattern matching is replaced by passing a closure for each variant of the enum, and only the one that has the right variant will get called.
  • stabby, similarly to abi_stable, has its own version of trait objects. However, stabby supports multi-trait objects (which rust doesn't), and can represent closures and futures in its trait-object system (which abi_stable can't, or at least not last I checked).
    • Sadly, Waker is not ABI-stable, and can't be destructured completely, so they have to be moved into an allocation to guarantee ABI-stability when calling futures :(
    • Through the unsafe_wakers feature (which I forgot to expose in 0.1.0, so you get 0.1.1 immediately), you can decide to entrust your fate to rustc, and have stabby pass the waker as if it was ABI-stable (you may need to pray when doing that)
  • In the near future, I plan on making proc-macros to wrap functions with a checker that will run once when acquiring the symbol to verify through reflection that both link-units agree on the types they're going to exchange.

I hope you like stabby :)