Looking Back on Swift 3 and Ahead to Swift 4
From our experience with Swift 3, we know we need to pick and choose what we’re going to tackle. For Swift 4, the primary goals are to deliver on the promise of source stability from 3.0 on, and to provide ABI stability for the standard library.
[…]
String is one of the most important fundamental types in the language. The standard library leads have numerous ideas of how to improve the programming model for it, without jeopardizing the goals of providing a unicode-correct-by-default model. Our goal is to be better at string processing than Perl!
[…]
Adding an (opt-in) Cyclone/Rust inspired memory ownership model to Swift is highly desired by systems programmers and folks who want predictable and deterministic performance (for example, in real time audio processing code). More pertinent to the goals of Swift 4, this feature is important because it fundamentally shapes the ABI. It informs code generation for “inout”, how low-level “addressors” work in the ABI, impacts the Swift runtime, and will have a significant impact on the type system and name mangling.
[…]
The core team is committed to adding powerful dynamic features to Swift. For example, Swift 3 already added nearly all the infrastructure for data reflection (which is already used by the Xcode memory debugger). We should use this infrastructure to build out a powerful user-facing API. Similarly, we would like to design and build out the implementation for dynamic method reflection runtime + API support.
Update (2016-07-30): See also the ArsTechnica and Hacker News comments.
You can choose to use the memory ownership features by adding extra annotations, giving better performance and control over ARC. Right now we have very limited options for avoiding ARC overhead in critical loops, largely forcing you to drop down to unsafe constructs. We’d prefer the model to be “you can add more annotations to your code to get better performance, allowing the compiler statically verify correctness instead of dynamically”.
Memory ownership control is an extremely non-trivial feature, which will probably drive us to add first class move semantics and region types to the language. This will also call for significant standard library extensions. It will pay for this complexity by making it easy to ignore the complexity if you don’t want it, and by the fact that the standard library and other stuff can go much faster.
