Design note: ABI

Q: Is Cpp2 ABI-breaking, ABI-preserving, or ABI-neutral?

A: Neutral, and presents an opportunity.

ABI is an orthogonal issue. ABI is up to the platform vendor.

However, Cpp2 presents an opportunity because Cpp2 code inherently (and by design) gives us a "bubble of new code" that doesn't exist today, with the opportunity to make that code mean what we want it to mean without worrying about breaking changes... and that means we can make link-level ABI changes as well as source-level language changes.

For example, it would be easy to have Cpp2 functions use a specific platform-supported ABI without worrying about breaking link compatibility with any existing code. A simple example would be if cppfront were someday to emit all Cpp2 free functions on Windows as __stdcall-but-with-left-to-right-arguments-and-small-structs-in-registers-as-bjarne-the-creator-intended or whatever made sense.

Such ABI improvements can be desirable for performance and other reasons. For example, we might want a different Windows ABI for Cpp2 functions when passing std::span. See "std::span is not zero-cost on Microsoft ABI" and the Reddit discussion.

Q: What about evolving a Cpp2 function's/type's ABI?

A: I aim to address that as part of general versioning.

Once the basic language implementation is complete and fairly solid, one of the parts of the Cpp2 design that I haven't talked about yet and aim to get to is first-class support for versioning... including things like deprecation, and also exploring what that means for adding functions and data members to classes, including distinguishing between ABI-compatible changes ("minor" versions in my view) and ABI-breaking changes ("major" versions) and compile-time language support for committing to the version of a type you intend to use.