My view is that the second answer snippet, with which I agree, implies that the answer to the first snippet is: No, that is not the purpose of "a stable, modular ABI for Rust", which is the subject of this thread.
ABI interoperability with another language inherently restricts the ABI to concepts that are expressible in both languages.
repr(C) already accomplishes that purpose for concepts expressible in C.
repr(Swift) would accomplish the same for concepts that are mutually expressible in Rust and Swift.
But Rust has concepts (and constraints) that are not expressible in other languages. IMO a
repr(Rust) ABI should be an intra-language ABI (i.e., Rust to Rust) that provides interoperability among Rust compilation units, even when those units were generated by different compiler versions/point-releases. There is no way today to annotate Rust code so that such cross-version interoperation is guaranteed at designated interfaces (except by using
repr(C), thus dropping to the reduced subset of concepts expressible in C).
Another goal of this effort, IMO, is development of the in-language descriptive mechanisms needed to specify
repr(Rust), such as assignment of
enum variants to niches in a unified
enum representation (e.g.,
Option). The expectation is that such descriptive mechanisms will also be usable to specify inter-language ABIs (i.e, Rust to non-Rust) such as
repr(Swift). It is that latter potential that makes Rust a potential run-time bridging languages between binaries that use incompatible ABIs.