Yes. Note that they are intending to build it on top of the C ABI that already exists. So anything you can do with the new ABI, you can already do today. It just currently takes a lot of work. Every &[u8] slice you want to pass has to be rewritten as two arguments for pointer and length. That’s the easy stuff; error handling is as painful as it always is in C. You have to sit down and essentially bang out a C header file as Rust extern “C” functions, using error codes, fancy ways to represent error conditions as invalid return values (eg negative numbers) and all those tricks. Even if your target language is eg Swift and Swift can absolutely be taught to understand slice types, result types, nullable types etc, since it has all of these things natively. And then you have to write an actual C header file or use cbindgen, and then do the whole thing in reverse to climb back up to the high level types in the target language. As I said: a lot of work.
The general idea is for someone to eventually teach Swift about the slice type etc. When Swift defines the same mappings from its high level types (Optional etc) to C ABI representation as Rust does. And when that work is done you don’t need to drop down to banging out C headers and writing the repetitive conversion code on either end. All that would remain is keeping the “extern” declarations/imports in sync with the exports, which will be much easier once higher level types can be used easily in FFIs. Making an IDL to describe them is out of scope for now but clearly a possibility.
> You have to sit down and essentially bang out a C header file as Rust extern “C” functions, using error codes, fancy ways to represent error conditions as invalid return values (eg negative numbers) and all those tricks.
You have to do these things anyway if you want a Rust library to be accessible via C FFI, which is the preferred extern interface wrt. most programming languages. (Swift is an exception, since it was specifically designed to have a stable extern ABI).
The general idea is for someone to eventually teach Swift about the slice type etc. When Swift defines the same mappings from its high level types (Optional etc) to C ABI representation as Rust does. And when that work is done you don’t need to drop down to banging out C headers and writing the repetitive conversion code on either end. All that would remain is keeping the “extern” declarations/imports in sync with the exports, which will be much easier once higher level types can be used easily in FFIs. Making an IDL to describe them is out of scope for now but clearly a possibility.