Reply-to: Mohamed Koubaa <koubaa.m at gmail ~dot~ com>

Introduction

This paper discusses a set of extensions to C++ to standardize a compatibility ABI in some parts of the standard library and type system.  It is not meant to propose an ABI for all types and language features

Motivation and Scope

C ABI compatibility is often wrongly assumed and expected by C++ developers.  The language evolution often will introduce new types and features leaving the ABI unspecified.  Over time, code begins to depend on this ABI and changes to it become infeasible or impossible. This situation is not inherently c++ic (using Herb’s term).  It is simply a historical outcome based on where the language came from and its often shared runtime with C.

ABI is not a problem with most other popular languages and is really holding back the C++ ecosystem.  The way other languages deal with (or don't have to) are:

• C - Compatibility is a primary concern and the C ABI is practically how other languages often achieve ABI

• Python - See above.  Python extension modules (often written using C++!) are ABI compatible because the CPython interface is, well, C.

• JS/C#/Java - these languages use a virtual machine or interpreter so that the ABI design are outside of the domain of the everyday programmer and library author

After using C++ for some years I and others have the understanding that in order to have truly portable C++ code, it must be distributed as source code and built by clients.  Clients need to understand the (often varied) build systems and tests in order to use just about any useful C++ library.  This is a burden that is neither expected nor tolerated when using other compiled languages.

Another concern with the current state of affairs is that for any individual to be a competent software architect of large scale software systems (perhaps excluding distributed systems and microservices) needs to master the sharp edges around ABI compatibility.

One technique for building C++ code without dealing with ABI is called an hourglass pattern.  This means building a C layer at the interface of binaries and writing c++ code to wrap that C interface in a user friendly C++ API.  This is sometimes done using plain C and other times done using COM (on windows). Essentially, this is an admission that in order to have stable ABIs one must only use a small subset of C++ types and language features on the interface, and that subset is essentially C.   In the narrow center of the hourglass free functions for allocating and freeing memory, as well as errno() are often used and converted back into constructors, destructors and exceptions.

If a stable ABI is known which includes many important standard library types, language interop can become idiomatic.  For instance, a language consuming an exported method which returns a stable_vector can wrap that in the most appropriate language semantics.  I.e. IEnumerable/IList for C# or __len__ in python

Impact on the standard

This paper does *not* attempt to propose an ABI for the entirety of the c++ type system and library features.  Instead, a portion of the standard library (some existing, some new) will be marked as having a stable ABI, and library authors can opt into using that portion at the binary interface of libraries so that ABI compatibility is no longer a concern for their clients.  In spirit, this is no different than the hourglass pattern, except that the subset of C++ which can be considered to be ABI stable is larger than simply what is shared with C due to history. Examples of these types are the P0709 exception and ranges which are in c++20.  Examples of library features are a new stable_allocator and a std::stable metaclass which can be used for compile time reflection on classes to ensure that they are indeed stable.

Other language features are explicitly not expected to be stable and implementations of c++ can change their ABI at any time.  In practice it will likely be difficult for an implementation to do that until using stable ABIs at binary interfaces becomes a common practice.

Technical Specifications

This proposal introduces the notion of stable, a property of a type or feature whose ABI is defined to never change.  Stable can be thought of as a superset of is_standard_layout because ABI concerns extend beyond memory layout.  All types and language features are considered unstable unless explicitly defined as stable. Following are the list of all stable types and language features (there are not many):

• Standard layout

• P0709 exceptions

• Stable_allocator

• Fixed width integer types

• Range

• String_view

• Array

• Stable_vector

• Stable_string

This set of types and features may grow slowly over time, much like constexpr did since c++11, except with less urgency and with no interest in someday covering the entire language.

std::stable_allocator

This proposal defines a std::stable_allocator which controls the behavior of the new and delete functions and fixes them to a given version of malloc() and free() on a given platform.  For instance, the windows platform has multiple C runtimes to choose from. Classes that have an allocator template argument and whose clients provide stable_allocator are such that any new and delete function that occurs in their member functions will use the stable allocator.  This will allow such a class to be allocated in one binary unit and deleted in another without worrying about the runtime of each unit.

std::stable metaclass

The std::stable metaclass can be used for types that which to declare themselves as ABI stable.  The class will fail to compile if any unstable types or features are used at the interface of such a class.

Modules

This proposal does not intend to provide any relationship between modules and the notion of stability.  Modules may include all language features which is larger in scope than stable ABI features. However, if a standard attribute is added for visible symbols/dll export (does this exist yet?), compilers may warn about any unstable types or features used in conjunction with that attribute.