Evolving ABI Stable Language

Evolution Discussion
1

I am unclear on the impact of ABI stability on the future evolution of the language. From several comments in the forums I got the impression it will in effect freeze the status quo forever. I feel like there are still several aspects of the Swift (compiler and standard library) that are not fully baked. The impression I got was that only additive API changes will be possible after ABI stability.

Because I don’t know much about the internals of the runtime or all the tricks available to the compiler, I would very much appreciate if somebody explained the boundaries of future Swift evolution.

Some concrete concerns:

  • Is revamping the type hierarchy possible (Sequence & co.)?
  • Will defer implementation always have to be a closure under the hood? (iff true :thinking::man_shrugging:)
  • Type erasure and everything around Any* wrappers
2 Likes
2

I think this overstates matters. There are many changes and additions that can be made without breaking the ABI.

This is true, but the old APIs can still be deprecated. After a certain point it becomes harder to justify breaking working code.

Sure, as long as you keep the old stuff around or restrict your changes to just adding new protocol requirements with default implementations expressed in terms of the existing requirements.

No, defer is completely internal to a function's body and does not affect the ABI.

1 Like
3

However I'd be curious to hear about what problem you're having with defer that stems from its implementation in terms of a closure. We could certainly change how its implemented if it would fix a concrete problem.

2 Likes