Welcome to Issue #9 of the weekly brief! Because issues are zero-indexed, this means we’ve reached our 10th issue milestone. 🎉 Thanks for reading each week! 😄 Things seem to have slightly slowed down this week. Even the Xcode 7.3 beta 3 release notes were mostly uneventful. It feels like we’re getting closer to the final Xcode 7.3 and Swift 2.2 releases.

Commits and pull requests

John Holdsworth merged a pull request that fixes a missing Xcode “Quick Help” menu for enum values as switch case patterns. 👏

Dmitri Gribenko started work on enabling iOS host tests.

David Grove from IBM Research merged an initial integration of Swift overlay into libdispatch build, and made changes to allow building corelibs-libdispatch and corelibs-foundation together.

Brian Gesiak asked for Apple CI to cover corelibs-xctest, and now it does! 😎

The Swift Benchmark Suite is now open source! “The suite contains source code for benchmarks, libraries, and utilities designed to help track Swift performance and catch performance regressions before they are committed.”

Nadav Rotem improved the metadata hashing function in the Swift runtime. 🤓

Proposals

Daniel Dunbar has prepared a new proposal, “Package Manager C Language Target Support”. (Here)

This is a proposal for adding initial package manager support for the C, C++, Objective-C, and Objective-C++ languages. […] We would like Swift packages to be able to include C targets which can be exposed to Swift directly as part of a single package. This gives developers a simple mechanism for “falling back” to C…

The mailing list thread started here back in January, but it looks like Daniel is just now submitting the pull request. Overall, support for this seems positive, though a lower priority for the SPM team. If accepted, the Swift Package Manager could potentially replace CocoaPods — but I doubt this will happen soon. 😁 Also related, Ricardo Olivieri from IBM started a similar thread regarding external dependencies and SPM.

Joe Groff’s “Property Behaviors” proposal (SE-0030) is now under review. This was introduced awhile back on the mailing list, and I think the community was overwhelmingly excited about this. I’m sure it will be accepted.

Chris Lattner’s proposal, “Remove implicit tuple splat behavior from function applications” (SE-0029), has been accepted for Swift 3. Currently, instead of calling a function in the typical way, you can actually pass an N-tuple for the arguments instead. This little-known feature is being removed from Swift 3, as it is purely syntactic sugar.

// some function
func foo(a: Int, b: Int) { }

// normal call
foo(42, b: 17)

// using "tuple splat"
let x = (1, b: 2)
foo(x)

Much of the feedback on this was “I’ve never used this”, so I doubt it will be missed. However, Brent Royal-Gordon has already started a discussion about a replacement.

Mailing lists

Félix Cloutier started a discussion about garbage collection. Joe Groff and Chris Lattner elaborated on the benefits and tradeoffs of reference counting versus generational mark-and-sweep. Joe also noted some historical, painful lessons learned with trying mark-and-sweep, while Austen Zheng reminded us of Android’s woes in this area.

Jordan Rose asked for feedback on library evolution support in Swift (“resilience”). This is not quite a proposal and will not go through the formal Swift Evolution proposal process, but feedback is encouraged! You can find the full document here.

After a ton of feedback from the community, Dave Abrahams revised his ideas from his initial thread on “when to use argument labels (a new approach)” and started a new thread to continue the discussion. If you have not been following along, the idea is exactly what the title describes. For example, which of the following is more appropriate: a.moveFrom(b, to: c) or a.move(from: b, to: c)? Of course, the full discussion is much more nuanced. One major goal of the API guidelines will be to help answer questions like this.