Question for the HN language designers: do you think it's possible to provide ABI stability when the language still doesn't provide the full promised features for concurrency ? (ex: async / await, agent based concurrency, and all the features talked about in chris lattner's concurrency manifesto)
An ABI can't really be "additive". If you add stuff to an ABI, it's a new ABI. Unless you tweak the definition of ABI to your liking (like introducing new concepts as "module stability").
Let's say you have an iOS application written in Swift 5 and you are using AlamoFire. The original promise of an ABI (like the C ABI, the ObjC ABI, COM, JVM, etc) is that AlamoFire could choose to switch to Swift 6 because of the great new async/await features, and you could still use that binary in your Swift 5 application. Because, you know, there is a stable ABI ;-)
If you enhance the ABI, that won't be usually possible. E.g. the Swift 5 program won't understand the "new mangling and calling convention" mentioned in the link. Presumably it could be bridged somehow, or maybe not in a useful way ...
> An ABI can't really be "additive". If you add stuff to an ABI, it's a new ABI.
Not really. You can add new concepts to an ABI without breaking existing code.
Suppose version N+1 of some compiler adds a new language feature, like async/await or whatever. It might involve a new calling convention and symbol mangling for async functions. However non-async functions would not be affected.
Of course if the library author removes old entry points they will break old client apps, but that's not a property of the compiler.
