Being able to change things. It's like all downsides of backwards compatibility but on a binary level
As to things ABI prevents:
- scoped_lock was added to not break ABI by modifying lock_guard
- int128_t has never been standardized because modifying intmax_t is an ABI break. Although if you ask me, intmax_t should just be deprecated.
- unique_ptr could fit in register with language modifications, which would be needed to make it zero-overhead, compared to a pointer
- Many changes to error_code were rejected because they would break ABI
- status_code raised ABI concerns
- A proposal to add a filter to recursive_directory_iterator was rejected because it was an ABI break
- A proposal to make most of <cstring> constexpr (including strlen) will probably die because it would be an ABI break.
- Adding UTF-8 support to regex is an ABI break
- Adding support for realloc or returning the allocated size is an ABI break for polymorphic allocators
- Making destructors implicitly virtual in polymorphic classes
- Return type of push_back could be improved with an ABI break
- Improving shared_ptr would be an ABI break
- [[no_unique_address]] could be inferred by the compiler should we not care at all about ABI
> Making destructors implicitly virtual in polymorphic classes
Not sure what to think of this one. Either one introduces a new keyword to opt out (not great), or all public destructors of an abstract base class are implicitly marked virtual (not great and another "hidden" language feature like threadsafe-statics).
After all, an abstract base class does not need its destructor to be public.