
Matt Gruenke wrote:
On Monday, July 7, 2025 3:40 PM, Jakob Lövhall wrote:
It is more like a fence, or wall, blocking improvement imho.
It doesn't block all improvements, nor would I envision a scenario where strict ABI compatibility is required over an extended range of releases. I merely suggested that ABI-breaking changes might be managed in some way, rather than being completely ad hoc.
That's completely impractical for Boost. Managing ABI-breaking changes in some way, in any way, is not just a matter of saying so. It's exceedingly hard. Even knowing, to a reasonable degree of certainty, whether there was an ABI break would be very hard for us because it would require test infrastructure we don't currently have, to be managed by people we don't currently have. And that's even without taking into account things like, say, the result of mp_unique<mp_list<int, float, int>> changing from mp_list<int, float> to mp_list<float, int> being potentially an ABI break. There's no ABI here anywhere, right? mp11 is purely compile time. And yet, if a type changes from X<int, float> to X<float, int> as a result, you'd have a potential ABI break somewhere, far removed from the mp11 change.