4 ms·
ABI stability is one of those things that seems obvious ("sane"), until you try to implement ABI-stable unboxed generics and discover that the amount of complex
by pcwalton 2y ago
ABI stability is one of those things that seems obvious ("sane"), until you try to implement ABI-stable unboxed generics and discover that the amount of complexity you incur, as well as the performance tax, is absurd. The code bloat with the resulting "intensional type analysis" actually makes the compile time worse (and the runtime far worse) than just specializing generics in many cases.
- zozbot234 2y agoThe Swift folks seem to manage just fine.
- pcwalton 2y agoThe amount of complexity that Swift has to deal with in order to make ABI stability work is exactly what I'm talking about. It's astronomical. Furthermore, it's only partial: there are some generics in which they couldn't afford the price of ABI stability, so they're marked inline and aren't ABI stable.
- kldx 2y agoI like Aria's writing about this https://faultlore.com/blah/swift-abi/ https://faultlore.com/blah/swift-abi/.
- throwaway17_17 2y agoIn this case (i.e. Rust specifically) what do unboxed generics mean. Without actually knowing Rust I don’t think I can analogize to either type theory or another language. I assume if I can figure out what they are I infer why they are difficult to compile.
- zozbot234 2y agoIt means ABI-stable interfaces (i.e. interfaces between separately-compiled "crates"/libraries, including dylibs and shared objects) can involve arbitrarily complex types with possibly nested generics, and these are implemented behind a single pointer dereference at most. This requires something a lot like dyn trait object vtables in Rust ("witness tables") except quite a bit more complex.