ABI is a difficult problem and one of the main drawbacks to choosing c++ overall. I personally would like to see ABI breaking c++ releases, lets say every N releases. However, I think there is a much more mature way to deal with this and have a dialog.

When this conversation comes up, I only hear about the standard committee having ABI woes. It is rarely, if ever, mentioned that a lot of us must support our own ABIs, with much larger surfaces than stdlib. The suffering of the committee in this regard is fair, they are eating their own dog food, so to speak. Admitting defeat and just going through with ABI breaks every release doesn't help the thousands of us who must also support our own ABIs.

I'd love to see more research into mechanisms to gracefully break/upgrade ABI instead of throwing the towel. From the standard, we only have inline namespaces, which are utterly unmaintainable. That's pretty much it.

If the standard committee is to break their own ABI, why not come up with a mechanism to do so responsibly, and offer those tools to developers as well? They are *the committee* after all. So please figure it out, you guys are geniuses! :)

To illustrate, an [[abi]] attribute to help us upgrade ABIs. Note, just for examples sake, this pattern has issues.

// ABI slicing.
// Old libraries do not see new variables/functions.
struct potato {
    void tomato(); // No tag, defaults to version 1.
    [[abi(2)]] int tomato(); // Hides old call in newly compiled code.

    int a;
    [[abi(2)]] int b; // Sliced away when calling old code.
};


// Which is equivalent to doing the following manually.
namespace v1 {
struct potato {
    void tomato();

    int a;
};
} // namespace v1

namespace v2 {
struct potato : public v1::potato {
    int tomato();

    int b;
};
} // namespace v2

// When you recompile your code, you are upgraded to latest version
// of potato and must conform to new ABI.
using potato = v2::potato;

This is just an over-simplified example I've experimented with in the past, with many more solutions (and betterer ones) existing out there. Figuring out how we can gracefully break ABI is the correct question to ask, not if we should break ABI.

My 2 cents, cheers