That’s a very helpful link, thanks!
I understood the talk correctly, I still think it should be possible to have some interoperability with Swift’s generics, just without true monomorphisation. Rust’s monomorphised version would just be a still generic-ish code calling Swift’s runtime.
Swift provides “witness tables” for generic types that describe their size, alignment and a sort of vtable for basic operations like copy or destroy. I don’t know if that can be made to agree with Rust’s move semantics. I suppose in the worst case non-Copy objects will all need to be SwiftRc<T>.
I’m not entirely sure how dynamic the tables are. Can the compiler read size/alignment, or is it really so dynamic that it could change at run time later? Lack of const fn size_of could be a problem for Rust. But OTOH Swift does monomorphisation as an optimization.
And finally Swift allows generic types like struct Pair<T> to be treated as opaque types accessed only via witness tables. For Rust that would be a question whether it should be exposed explicitly as methods or whether “direct” field access could be actually dynamic for #[repr(swift)] (desugaring to calls in MIR?).
And finally one thing I’ve noticed that the ABI does not define generic type bounds (where T: Eq). It assumes that for type checking the compiler has access to the source. That’s a bit of a bummer, because that means generics won’t be safe to use only based on ABI alone, and will need equivalent of bindgen to get the bounds.
