Swift 2.2 has been released! It includes contributions from 212 non-Apple contributors and 7 Swift evolution proposals. Be sure to read Ted Kremenek’s announcement on the mailing list for more details. The final version of Xcode 7.3 was also released, which includes Swift 2.2 and other improvements. Hopefully you were able to upgrade successfully. 😅

Regarding new features, I agree with Ayaka that having non-stringly-typed Objective-C selectors is so great. And of course, there were a number of interesting announcements at Apple’s special event on Monday. This was my favorite new product. 😄

Lastly, in case you missed it, there’s now an official mailing list for Swift Weekly Brief! Subscribe now. 💌

Starter tasks

• SR-1020: Fix-it Delete “var” doesn’t delete space before parameter name
• SR-873: Python Benchmark Driver needs unit tests
• SR-804: Improve SwiftPM Testing Time

Suggestions from Brian Gesiak:

• SR-1046: Make sure we use the same test runner executable for both the Swift and swift-corelibs-xctest builds.
• SR-1047: Test the Python used in the swift-corelibs-xctest project as part of the XCTest test suite.
• SR-1048: Build debug/release versions of swift-corelibs-xctest when building debug/release versions of Swift.

This task from last week is still up for grabs:

• SR-875: Improve regex support in the swift-corelibs-xctest test suite. This’ll make it easier to write tests for that project.

Submit a task by sending a pull request or opening an issue.

Commits and pull requests

I noticed that @swift-ci expanded its repertoire recently. When first announced, the core team could trigger running the full test suite by commenting “@swift-ci Please test” on pull requests. Now, commenting “@swift-ci Please smoke test” will only build the target projects to make sure they build successfully. @swift-ci can also merge with “@swift-ci Please test and merge”. Even more, there’s “@swift-ci Please perf test” which will run performance tests and then leave a comment noting any regressions, improvements, and unchanged results for both -O and -Onone optimization levels. 😎 If only we could say, please fix… 😂

Shawn Erickson submitted a pull request to unify mutexes in the Swift runtime, resolving SR-946.

Daniel Eggert started work on implementing NSURLSession. It’s implemented using libcurl and currently a work-in-progress. 👏

Jesse Rusak opened a pull request that implements proposal SE-0037: Clarify interaction between comments & operators. This proposal was accepted as a bug, and resolves SR-186 and SR-960.

Taylor Franklin implemented the remaining NSDateFormatter attributes and added more tests, resolving SR-208.

Ian Partridge submitted a pull request that implements NSJSONSerialization.dataWithJSONObject(_:options:).

Slava Pestov fixed leaking the error value when using try?, resolving SR-972.

David Grove of IBM opened a pull request to rework the corelibs-libdispatch overlay for Linux. It resolves SR-739, SR-740, SR-737. “This commit fixes all of these issues by injecting a complete Swift overlay layer that wraps the native libdispatch objects and native APIs.”

Yan Li submitted a pull request that implements the basic initializers for NSAttributedString.

Arnold Schwaighofer opened a pull request to make String’s comparison and hash function faster on platforms that use Objective-C inter-op by using a stack allocated _NSContiguousString. The change provides a 1.2x to 2.2x speedup. 😎

Arsen Gasparyan merged a patch that replaced if true { } with do { } in some test files. Odd. 🤔 My guess is that these tests predated the introduction of do { }? In any case, consider this your occasional reminder that there are always opportunities for small, easy wins like code cleanup. Get involved!

Another interesting thing I noticed was in Neil Kimmett’s pull request to add .zero convenience static vars for UIEdgeInsets and UIOffset. This required internal discussion with the UIKit team to get approval for the change. 😳

Proposals

Andrew Bennett’s proposal, SE-0043: Declare variables in case labels with multiple patterns, has been accepted for Swift 3. “This is a simple and clean extension to the pattern matching model in Swift, positively received by both the community at large and the core team.” Greg Titus has already implemented the change on master! 👏

Joe Groff’s proposal, SE-0042: Flattening the function type of unapplied method references, has been accepted for Swift 3. “The core team and most of the community agree that this proposal would increase the usability of the functional features in Swift, and eliminates a class of problems that occur with inout parameters.” This work is being tracked at SR-1051.

Adrian Kashivskyy’s and Erica Sadun’s proposal, SE-0047: Defaulting non-Void functions so they warn on unused results, has been accepted with revision for Swift 3. This work is being tracked at SR-1052.

The core team and much of the community agree that this proposal directly aligns with the spirit of the Swift language, making it so that the compiler will warn about obvious omissions in code that may be bugs. The @discardableResult attribute provides a good way for API authors to indicate that their functions and methods produce a non-essential result, and should not produce this warning. […]

While this seems like a great direction for the standard library and other pure-Swift code, its impact on imported C and Objective-C APIs is less clear. […] As such, the core team requests that this proposal be revised to indicate that the Clang importer will automatically add the @discardableResult attribute to all non-Void imported declarations…

Michael Ilseman’s proposal, SE-0044: Import as member, has been accepted, though the version of Swift is not specified. “While there wasn’t a huge amount of feedback, all of the feedback received was positive. During the review period, the proposal was amended to support mapping getter/setter functions to subscripts (via the swift_name attribute) and to support importing instance members into an extension of an Objective-C protocol.” Work for this is happening on the import-as-member branch.

Michael Buckley’s proposal, SE-0016: Add initializers to Int and UInt to convert from UnsafePointer and UnsafeMutablePointer, is now under review. From the introduction: “Just as users can create Unsafe[Mutable]Pointers from Ints and UInts, they should be able to create Ints and UInts from Unsafe[Mutable]Pointers. This will allow users to call C functions with intptr_t and uintptr_t parameters, and will allow users to perform more advanced pointer arithmetic than is allowed by UnsafePointers.” It seems like a rather straightforward API change that will improve inter-op with C. There isn’t much feedback on the mailing lists, but so far it’s positive.

Chris Willmore has prepared a proposal, SE-0054: Abolish ImplicitlyUnwrappedOptional type, after discussions on the mailing lists. There was mixed feedback during the drafting process and the status of the proposal is now awaiting review.

The ImplicitlyUnwrappedOptional (IUO) type is a valuable tool for importing Objective-C APIs where the nullability of a parameter or return type is unspecified. It also represents a convenient mechanism for working through definite initialization problems in initializers. However, IUOs are a transitional technology…

This proposal seeks to limit the adoption of IUOs to places where they are actually required, and put the Swift language on the path to removing implicitly unwrapped optionals from the system entirely when other technologies render them unnecessary.

Nicholas Maccharoli has prepared a proposal, SE-0053: Remove explicit use of let from Function Parameters, after discussions on the mailing lists. “Since function parameters are immutable by default, allowing function parameters to be explicitly labeled as let is a bit of a syntactic redundancy that would best be removed.” Feedback on the lists is positive. I’m surprised Erica Sadun didn’t think of this first. 😉

Patrick Pijnappel not only prepared a proposal, SE-0052: Change IteratorType post-nil guarantee, but already submitted a pull request for the change. 👏 “Currently, the documentation for IteratorType.next() has the precondition that when calling next(), no preceding call to next() should have returned nil, and in fact encourages implementations to raise a preconditionFailure() for violations of this requirement. However, all current 27 IteratorType implementations in the standard library return nil indefinitely.” His proposed solution is to bring the guarantee in line with the common expectation, and require iterators to return nil indefinitely.

Mailing lists

Timothy Wood started a discussion about updating the signature of the ObjectiveC.autoreleasepool function to add rethrows (SR-842), and drafted a proposal. “The autoreleasepool function in the standard library does not currently support a return value or error handling, making it difficult and error-prone to pass results or errors from the body to the calling context.”

Chris Lattner started a thread to revive discussions on proposal SE-0025: Scoped Access Level.

To summarize the place we’d like to end up:

• “public” -> symbol visible outside the current module.
• “internal” -> symbol visible within the current module.
• unknown -> symbol visible within the current file.
• “private” -> symbol visible within the current declaration (class, extension, etc).

The rationale here is that this aligns Swift with common art seen in other languages, and that many people using private today don’t want visibility out of their current declaration. It also encourages “extension oriented programming”, at least it will when some of the other restrictions on extensions are lifted. We discussed dropping the third one entirely, but think it is a useful and important level of access control, and when/if we ever get the ability to write unit tests inside of the file that defines the functionality, they will be a nicer solution to @testable.

The thing we need to know is what the spelling should be for the third one…

As you can imagine, an explicit request for bikeshedding has resulted in a tremendous thread. It looks like the consensus so far is for private, private(module), private(file) — which James Berry suggested. I think this is great. 👍 Shawn Erickson pointed out that this puts the current private(set) in an awkward position, but it’s always been weird anyway.

Finally

And finally — from now on, we shall refer to “compiler bugs” as not-yet-implemented features. 😄 Feel free to assign any tasks to Dave Abrahams. 😉