The Swift.org community is finishing up its second full week of open source development. If you were hoping for a quiet week, you will definitely be disappointed. There is still a ton of activity with no signs of slowing down. The Swift team continues to work openly and to be encouraging to contributors. This week brought more crash fixes and more Swift Evolution proposals. Let’s get to it — the weekly brief!
Craig Federighi reflects on Swift’s first week out in the open with John Gruber on The Talk Show. I really enjoyed listening to this episode and continue to be surprised by Apple’s openness! The interview is only about 30 minutes. There is also a transcript on Daring Fireball.
One clarification from last week — currying will not removed completely, just the syntax.
Commits and pull requests
Dominique d’Argent introduced the first unicode variable name in his implementation of
NSAffineTransform. This is the only one that I’ve seen so far. I will happily buy a ☕ or 🍺 for anyone who can successfully merge a pull request that uses 💩.
William Dillon began support for ARMv7 hosts such as the Raspberry Pi, BeagleBone, and Nvidia Tegras.
The first independent Swift language evolution proposal has been accepted! You can say goodbye to C-style for-loops and say thank you to Erica Sadun. Beginning in Swift 2.2, you’ll see warning if you use a C-style for-loop and it will be removed in the 3.0 release. “For the most part, there was agreement that C-style for loops are quite rare in Swift code, and most of the existing uses would be better written as for-in loops.” Also be sure to note the two potential problems with this change as described in the announcement.
Max Howell, Daniel Dunbar, and Mattt Thompson have prepared a proposal to add testing support to the Swift package manager! “Testing is an essential part of modern software development. Tight integration of testing into the Swift Package Manager will help ensure a stable and reliable packaging ecosystem. We propose to extend our conventional package directory layout to accommodate test modules.”
Max Moiseev’s proposal to constrain
AnySequence.init is due for review this week. I don’t see any reason why this would not be accepted. “These constraints, in fact, should be applied to
SequenceType protocol itself (although, that is not currently possible), as we expect every
SequenceType implementation to satisfy them already.”
David Hart’s proposal to require
self for accessing instance members is currently under review. If you haven’t been following along, this would make
self always required even when it can be inferred implicitly. For example, using
self.view versus simply
view. There’s a ton of discussion on the mailing list and twitter. I’m not a fan, but I can understand some of the arguments to do this.
Erica Sadun also has a great post detailing some of the recent proposals.
There’s an interesting thread on dynamic versus static method dispatch. From Chris Lattner: “TL;DR: What I’m really getting at is that the old static vs dynamic trope is at the very least only half of the story. You really need to include the compilation model and thus the resultant programmer model into the story, and the programmer model is what really matters.”
Fabian Ehrentraud started a discussion around improving crash-safety when importing Objective-C code without nullability attributes. Currently, un-annotated Objective-C members are bridged to Swift as implicitly unwrapped optionals (e.g.,
view!). This proposal suggests importing these members as optionals (
view?) instead, which would encourage clients to handle possible
nil values safely. Sounds great to me. Honestly, I’m not sure why implicitly unwrapped optionals exist to begin with, as they seem contrary to Swift’s safety goals.
Colin Cornaby suggested removing semi-colons completely from Swift following the trend of removing C-style language features. As noted on the mailing list, while semi-colons are often syntactic noise, they do serve a stylistic purpose for grouping similar statements on the same line. I could go either way on this, but it doesn’t seem like the idea is gaining enough traction to warrant a formal proposal.
Stare long enough into the language design, and the language design stares back into you.
That’s it for this week! Stay tuned. And if you have suggestions for the next brief, send me a link.