3 ms·
The real problem with ABI breaks isn't so much the need to (automatically or manually) migrate legacy programs, but that so much of modern software is comprised
by jcranmer 2y ago
The real problem with ABI breaks isn't so much the need to (automatically or manually) migrate legacy programs, but that so much of modern software is comprised of multiple pieces that don't have any way to coordinate a lock-step ABI migration.
Take something like std::unique_ptr. The basic problem is that it is absolutely capable of being written such that std::unique_ptr<T> has the same ABI as T, but it doesn't (instead acting as a T*). It's pretty damn trivial to write the necessary thunking between the ABI versions, so it's also absolutely possible to have both old-ABI and new-ABI coexist (something that was a lot more difficult for the infamous Python 2->3 transition). And other than the internal changes needed to give it a new ABI, there's not really any user-visible API that would need to be migrated. But it still can't be done because std::unique_ptr is used on the interface between library A and B, and how is A supposed to know which version of the ABI B is expecting, when neither A nor B?