Issue #42 13 Oct 2016
Written by: Bas Broek
Swift 3? You mean Swift 4? Apple has further outlined their plans on the next version of Swift. And as a reminder, Chris Lattner explained back in July what’s in store for Swift 4 and its release plan. Forwards!
- SR-2902: [Compiler] Add a timer and debug flag for expression type checking. (Thanks Ben Asher!)
- SR-2910: [Compiler] Log property name for synthesized properties in
-debug-time-function-bodiesoutput (Thanks Ben Asher!)
Ole Begemann wrote a great post on Optional Non-Escaping Closures. In Swift 3, non-escaping closure are the default. If you are still confused about how/when to use
@escaping, this is a great read. Ole also explores some finer details and gotchas.
Commits and pull requests
Doug Gregor updated the swift-evolution repository for Swift 4 stage 1. 🎉 Swift 4.0’s expected release date is late 2017, so mark your calendars!
Michael Ilseman committed changes to allow Swift version compatibility checking for source-breaking changes. The recent change to
@escaping on variadic arguments is the first change to need specific Swift 3.0 compatibility.
Robert Widmann merged changes to reject standalone
$ as identifiers, which were accidentally accepted as valid. Chris Lattner pointed out that this is a source-breaking change (another!) — particularly for Dollar, a Swift library by Ankur Patel. The fixit for this was almost to rewrite
$ as 💲 (dollar sign emoji). 😂
Roman Levenstein opened a pull request that adds a flag to the SIL optimizer to inline generics.
Alex Blewitt continued making progress on implementing
NSDecimal in swift-corelibs-foundation.
Swift 3.0.1 Preview 3 was released!
No new proposals this week, but the status page has been updated to include Swift 3.0.1, Swift 3.1, and Swift 4.
Not on the mailing lists, but on Robert Widmann’s pull request mentioned above, Jordan Rose and Chris Lattner elaborate on how source-breaking changes will be handled.
We already passed that deadline: it was 3.0. At this point source-breaking changes need to be justified and will be handled on a case-by-case basis.
… but the process for doing this hasn’t been decided and written up yet.
Chris Lattner shed some light on the future dynamic aspects of Swift. “The core team is committed to adding powerful dynamic features to Swift.”
The primary reason that Swift currently lacks these features is simple prioritization. It has unfortunately not been the highest priority to build, because we already have working systems for all of those in Cocoa, and things like source stability and binary stability (among other things) are more important to the Swift community in the moment. As Swift evolves, they will bubble up in the priority list.
I know that having a read/write data reflection API is the top of the list for many people, and having the ability to reflect on methods is also important for some patterns. I look forward to the community having the bandwidth to properly design and debate these things, because I’m confident that there are good answers for these.
That said, to be clear, this is definitely out of scope for Swift 4 Stage 1, which is our current mode. We need to stay focused in the short term on the most pressing issues, which revolve around Source and ABI stability.
We are willing to make the internal implementation of Swift complex if that means that we get a beautiful model for programmers.
— Chris Lattner 👏