Cyclone/Rust-inspired memory ownership model is highly desired by systems programmers and for other high-performance applications that want predictable and deterministic performance. This feature will fundamentally shape the ABI, from low-level language concerns such as "inout" and low-level "addressors" to its impact on the standard library.We don’t know how Swift’s memory handling may change, though the mention of ABI could be telling. Currently, Swift uses a Rust-style memory management, but encourages what’s called ‘heap’ management that takes advantage of Automatic Reference Counting (ARC) rather than garbage collection. The other two memory models available to both – static and stack allocation – are more prominent in Rust, which is typically more efficient. It’s also a bit harder to grasp, so expect to be learning a lot more about memory; the days of shrugging and assuming ARC will automatically manage app memory may be coming to an end. If you need even more to look forward to with Swift 4.0, the post notes the second release will feature “a few other large and small features.” No word on what those may be, but we’re excited to find out.
Swift 4.0 is in development, according to a posting to its GitHub repository. While no mention of version 4.0 has been made on the official Swift website, the open-source arm details what we can look forward to. Specifically, Swift 4.0 will bring stability to the language – especially with regard to legacy support. It will also be divided into two release cycles, with a complete rollout expected by late 2017. The Swift team says the first release of Swift 4.0 will bring overall stability to the source and binary interface, or ABI. The language will be developed to support different versions, so developers can avoid those finicky ‘update your code’ messages in Xcode. Resilience is also a priority for Swift 4.0, where ABI improvements will help APIs become more powerful. The aim is to allow APIs to be dynamic without breaking the ABI. The team writes that the ABI improvement involves “a ton of small details that need to be audited,” which is likely the reason it will wait for 2017. Standard library improvements will also factor, and help the ABI become stronger. Currently, workarounds for niggling issues exist, but leaving them unchecked makes them part of Swift's core – and that directly violates the aim of having dynamic APIs that don’t break the binary. If you’ve got loose ends, you don’t have a solid foundation. Changes to the memory model in Swift are also on the way, but the team is cryptic about what that means. Pegged for the second release of Swift 4.0, the GitHub post notes the following: