# A Stable Modular ABI for Rust

**URL:** <https://internals.rust-lang.org/t/a-stable-modular-abi-for-rust/12347>\
**Category:** compiler\
**Created:** [May 14, 2020, 6:14pm UTC](https://internals.rust-lang.org/t/a-stable-modular-abi-for-rust/12347 "2020-05-14T18:14:49Z")\
**Posts on this page:** 1\
**Showing post:** 136

<div class="post-metadata">

**Author:** ![zicklag](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/zicklag/32/5776_2.png) [@zicklag](https://internals.rust-lang.org/u/zicklag)\
**Post date:** [October 28, 2020, 7:45pm UTC](https://internals.rust-lang.org/t/a-stable-modular-abi-for-rust/12347/136 "2020-10-28T19:45:43Z")

</div>

> [@Tom-Phinney](#):
>
> 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.

Yes, I think primarily the goal of this effort is to produce a way to create ABI plugins for Rust that can be swapped out. The specification for this modular ABI mechanism should be able to _at least_ supply a stable Rust-to-Rust ABI **and** provide Rust-to-OtherLanguage ABIs.

---

_[View the full topic](https://internals.rust-lang.org/t/a-stable-modular-abi-for-rust/12347)._