Welcome to issue #13 of the weekly brief! This week Apple released beta 6 of iOS 9.3, watchOS 2.2, and OS X 10.11.4, with no new beta for Xcode 7.3 — the final release should be getting close!

Starter tasks

What’s this new section of the weekly brief?! Last week Brian Gesiak suggested including a list of introductory tasks to help beginners or new comers get involved. It’s an awesome idea, and should be super helpful for the community. However, finding good tasks can be rather involved and I already have trouble finding free time 😁 — so I’m asking for your help! 😄 If you come across a good starter task, let me know by opening an issue or pull request — or tweet to me or @swiftlybrief. Each week, I’ll list any submitted tasks here.

For this week, Brian has kindly offered a few suggestions:

  1. SR-907: Add convenience XCTestExpectation constructors
  2. SR-906: Allow XCTestCase.continueAfterFailure to be set
  3. SR-875: Make swift-corelibs-xctest Functional tests regex matching more like FileCheck

If you are unsure or intimidated about contributing, I know a guy that gave a talk about this recently that might help motivate you! 😉

Commits and pull requests

Anna Zaks added basic address sanitizer (ASan) support. This allows catching and diagnosing memory corruption errors, which are possible when using unsafe pointers. “This patch introduces a new driver/frontend option -sanitize=address to enable ASan function instrumentation.” 😎 Live dangerously. (I missed this from last week!)

Eugene Gubin submitted a fix to correct the wrong behavior of NSArray.indexOfObject(_: ...) in corelibs-foundation.

Max Howell merged Xcode project generation for Swift package manager. This is the start of the plans for Xcode integration in SPM. 👏

Dmitri Gribenko started work on the new collection indexing model for Swift 3.

Ankit Aggarwal merged changes to SPM that add -h and --help to swift test, and allow passing arguments to -XCTest directly. These changes were proposed in SE-0019, Package Manager Testing.

Shawn Erickson also contributed to the Swift 3 indexing model work-in-progress, building out the Collection.next(i: Index) -> Index APIs. 🙇

Brian Croom submitted a pull request to corelibs-xctest that allows selecting a particular test or test case to run from the command line. Very cool. 😎

Greg Titus started work on typealias versus associatedtype in protocols for Swift 3. These changes remove the Swift 2.2 use of typealias and make associatedtype required for generic constraints in protocols, and allow using typealias as an actual type alias.

Brian Gesiak committed adding the asynchronous testing API (XCTestCase.waitForExpectationsWithTimeout()) to corelibs-xctest. This means asynchronous testing is now available on Linux! 👏

Jason Molenda merged changes that allow Swift to be build for iphoneos-armv7s (used in Apple A6 and later 32-bit devices).

Ankit Aggarwal opened a pull request for a basic implementation of SE-0038, allow SPM to be used to create and build C libraries! 🎉 For clients, it looks like all you need to do is include your C sources and a .modulemap. 😎

Maxim Moiseev migrated corelibs-foundation and corelibs-xctest to Swift 3, per the Swift 3 API guidelines changes.

Proposals

Erica Sadun continued her rigorous effort in refining Swift, this time with proposal SE-0046: Establish consistent label behavior across all parameters including first labels. It was initially suggested by Joe Groff, and Erica took it from there.

“We propose to normalize the first parameter declaration in methods and functions. […] This will create a simple, consistent approach to parameter declaration throughout the Swift programming language and bring method and function declarations in-sync with initializers, which already use this standard.”

For example, supposed you have func foo(x: Int, y: Int). Before this change, calling the function would look like this: foo(2, y: 3). After this change, it becomes foo(x: 2, y: 3), which is currently how initializers behave. You could opt-out of this new behavior by declaring func foo(_ x: Int, y: Int) instead. 👏 Support for this is overwhelmingly positive and I couldn’t agree more! 🎉 I often find myself writing func foo(x x: Int, y: Int) and I hate it.

There was exciting news on swift-evolution last Thursday — after issue #12 was already out — the “big 3” proposals were all finally accepted with modifications. 😎 The summaries in the announcement emails provide a great overview, so follow the links below! Erica Sadun also has a great article on this.

// Objective-C
- (void)exchangeSubviewAtIndex:(NSInteger)index1
            withSubviewAtIndex:(NSInteger)index2;

// Swift
func exchangeSubview(at index1: Int, withSubviewAt index2: Int)

Proposal SE-0026: Abstract classes and methods has been deferred from Swift 3, but will be revisited in the future. While the core team acknowledges that Swift’s protocols (currently) fall short in providing all features of abstract classes, they simply do not have the bandwidth to participate in the design of such an important feature. After Swift 3 goals are met, if protocol deficiencies/limitations still exist, the team wants to reconsider this proposal. Personally, I would like to see advancements in protocols (stored properties, default implementations, etc.) instead of the introduction of abstract classes.

Jeff Kelley’s proposal, SE-0033: Import Objective-C Constants as Swift Types, has been accepted! This proposal aims to import groups of constants (typically strings) as enums. “There was clear consensus in both the review feedback I received and within the core team that this was a simple, obvious enhancement to the importing logic.”

Erica Sadun’s proposal, SE-0039: Modernizing Playground Literals, is now under review. This is a rather straight-forward — and very nice — syntax refinement for playground literals. I’m sure it will be accepted. 😄

Erica Sadun’s proposal, SE-0040: Replacing Equal Signs with Colons For Attribute Arguments, has been accepted for Swift 3! “The community and core team uniformly agree that this proposal increases uniformity in the swift language.” It’s really great to see these refinements! And once again, Daniel Duan has already submitted a pull request to implement this! 😎

Mailing lists

Russ Bishop started a thread on bridging and inter-op with Objective-C and drafted a new proposal, Allow Swift types to provide custom Objective-C representations. He suggests exposing the private protocol _ObjectiveCBridgeable as a public protocol ObjectiveCBridgeable to allow you to opt-in to controlling how types bridge from Swift to Objective-C by converting them into and back from an entirely separate @objc type. “This frees library authors to create truly native Swift APIs while still supporting Objective-C.” Feedback on the mailing lists is positive so far. From Doug Gregor: “I think this is definitely worthy of a proposal”.

Erica Sadun started an interesting discussion on adopting a new common error type outside the bounds of NSError. “Swift’s redesigned error mechanism differs significantly from NSError in that its primary consumer are API calls, via the try-catch mechanism and not end-users. I would not like Swift to be tied down to an archaic construct for the sake of consistency.” David Owens and Kevin Ballard provided some good feedback.

There’s been an on-going discussion about removing failable initializers and replacing them with throwable initializers, started by James Campbell. Overall, the community does not support this idea. Early on, Becca Royal-Gordon pointed out the unnecessary complexity and overhead of this approach. This week, Austin Zheng provided a well-articulated and very practical argument against this, “If the argument is that taking away init? is going to force Swift users to embrace the One True Path of Error Handling, I don’t think that’s going to happen. The more likely outcome is that people are going to wrap throwable initializers in factory methods returning optionals, and throw away whatever error returns.” I think failable initializers have the potential to be misused/abused/overused, and agree that throwable initializers would not provide any value. You can almost always design your APIs such that you don’t need init?.

Dmitri Gribenko posted a request for comment on a new collections model. “What does everyone think about requiring indices to conform to Hashable, in addition to the existing requirements for Equatable and Comparable? I don’t think this should limit any viable collection designs, and yet might be useful, for example, to store indices in a set.” It’s an interesting idea, though Pyry Jahkola pointed out that clients could simply enforce this on their own.

Joe Groff started a thread on universal equatability, hashability, and comparability. He outlines how and why Swift could provide universal behavior for ==, hashValue, and/or <. Feedback is mixed with concerns over correctness of default/generated definitions. Austin Zheng argued against this idea, while William Dillon gave it a +1.

Finally

And finally — Slava finally caught something useful in a code review. 😂