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!
Community
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.
It looks like @zhuowei started a port for Android. I really hope this project takes off. Writing Android apps in Swift could be a huge win for mobile developers.
One clarification from last week — currying will not removed completely, just the syntax.
Commits and pull requests
Slava Pestov pushed a commit that fixed 91 percent of the outstanding compiler crashers.
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 💩.
Bill Abt and David Grove from IBM made significant contributions to Swift and the core libraries! As Federighi mentioned on The Talk Show, IBM really wants to use Swift on the server.
Chris Lattner fixed a few more radars.
Daniel Duan submitted a pull request to optimize the Set collection type. The result is roughly a 42 percent speed improvement. Whoa!
@PracticalSwift fixed a ton of typos.
William Dillon began support for ARMv7 hosts such as the Raspberry Pi, BeagleBone, and Nvidia Tegras.
Brian Gesiak continued to pursue testing the XCTest framework, and in terms of number of commits, he is now the #3 contributor on corelibs-xctest.
Proposals
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.
Mailing lists
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.