3 ms·

According to the draft async/await proposal, the ABI changes are additive, so in that case yes. https://gist.github.com/lattner/429b9070918248274f25b714dcfc761

According to the draft async/await proposal, the ABI changes are additive, so in that case yes. https://gist.github.com/lattner/429b9070918248274f25b714dcfc7619 https://gist.github.com/lattner/429b9070918248274f25b714dcfc...

bsaul 8y ago
I'm asking because i've read somewhere that async/await was deeply intertwined with try/catch and error handling... EDIT: well, the link does address this concern, so i suppose everything should be fine..
helge5 8y ago
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 ...
- slavapestov 8y ago
  > 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.

3 ms·

According to the draft async/await proposal, the ABI changes are additive, so in that case yes. https://gist.github.com/lattner/429b9070918248274f25b714dcfc761

by favorited 8y ago

bsaul 8y ago
I'm asking because i've read somewhere that async/await was deeply intertwined with try/catch and error handling... EDIT: well, the link does address this concern, so i suppose everything should be fine..
helge5 8y ago
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 ...
- slavapestov 8y ago
  > 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.