Welcome to issue #16! Last week’s exciting news on the release of Swift 2.2 has been followed up by an official blog post detailing the new features. Check it out if you haven’t already.

Also of interest is that Apple started a new beta program for Safari, Safari Technology Preview. This doesn’t have much to do with Swift, but to me it seems like perhaps Swift’s openness is starting to influence more teams within Apple. Maybe? The recent CareKit announcement also supports this theory. Anyway, I’m still hoping for an open source Xcode. 😁

Starter tasks

  • SR-1112: Wrong suggestion by Fix-it for if let unused vars
  • SR-1022: Missing “unused result” warning for #selector
  • SR-1005: SwiftPM port to Foundation
  • SR-1111: Non-optimized builds should avoid redundant thick_to_objc_metatype conversions
  • SR-1115: Adding initializers to Int and UInt to convert from UnsafePointer and UnsafeMutablePointer (SE-0016)

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

Commits and pull requests

There’s a new Swift 2.2.x milestone on GitHub with 19 issues closed and 2 issues open (as of this writing). I haven’t seen official announcements about a Swift 2.2.1 (or 2.2.x) release, but it looks like this patch release will be coming soon.

Kyle Yoon completed a corelibs-xctest starter task that added XCTestCase.expectationForNotification(). This adds a convenient way to setup asynchronous tests for NSNotification on Linux. 👏

Mike Griepentrog opened a pull request for an initial implementation of NSURLCredential.

Jordan Rose opened a pull request for a work-in-progress for SE-0055: Make unsafe pointer nullability explicit using Optional.

Manav Gabhawala merged a pull request to clean up parsing of function parameter attributes, among other things. “This pull request cleans up parsing of parameter attributes by parsing the inout, let and var tokens better. It cleans up the implementation to work better with SE-0003 by giving better fix-its and diagnostics for var as parameter attributes. It implements SE-0053 to disallow let as an attribute. It provides better fix-its for inout that are either duplicated or misplaced to better implement SE-0031.” 😎

Joe Groff opened a pull request to fix crashes when calling C functions imported as protocol extension methods.

Pushkar Kulkarni fixed a stack corruption issue in CFRegularExpression. 🤓

Nate Cook merged a pull request that makes Array’s conformance to RangeReplaceableCollection visible.

Joe Groff added support for importing Objective-C generics as generic classes in Swift.

Brian Gesiak opened a pull request that adds XCTestSuite announcements to corelibs-xctest. “This makes the swift-corelibs-xctest and Apple XCTest versions of XCTestObservation identical, bringing us closer to our Swift 3 goal of API parity.” 🙌

@tinysun212 made the stdlib random functions portable by removing arc4random and using C++ <random> instead. This allowed Dmitri Gribenko to drop the dependency on libbsd.

Chris Bailey implemented a missing NSString initializer in corelibs-foundation:

public convenience init(format: String, locale: AnyObject?, arguments argList: CVaListPointer)

Jordan Rose fixed rdar://24547884, addressing an issue in the ClangImporter where inherited protocol conformances were not set up correctly. “This is rdar://problem/24547884, which includes a reference to facebook/AsyncDisplayKit#1109. (As in, this should fix that issue as well. The test case in the Radar included a stripped-down client but the full AsyncDisplayKit.)”

Brian Gesiak opened a pull request that refactors the Cygwin toolchain to address “a great deal of duplication” across the various toolchains.

Proposals

Nicholas Maccharoli’s proposal, SE-0053: Remove explicit use of let from Function Parameters, has been reviewed and accepted for Swift 3. “Everyone agrees that including this redundant syntax is pointless given that the var/inout syntax has been removed or moved, it probably should have been included with SE-0003.” As noted above, Manav Gabhawala has a pull request opened to implement this. 👏

Michael Buckley’s proposal, SE-0016: Add initializers to Int and UInt to convert from UnsafePointer and UnsafeMutablePointer, has been accepted for Swift 3. “This rounds out a missing aspect of our unsafe pointer APIs. Where it was possible to convert Int/UInt to unsafe pointer, it wasn’t possible to convert back (without using unsafeBitcast). Adding these converting initializers fixes this…” This worked is being tracked at SR-1115.

Chris Lattner’s proposal, SE-0048: Generic Type Aliases, is now under review. “This proposal aims to add generic typealiases to Swift.” Pretty straightforward! The proposal would allow things like typealias Vec3<T> = (T, T, T). On the lists there are a lot of +1’s. 😄

Jordan Rose’s proposal, SE-0055: Make unsafe pointer nullability explicit using Optional, is now under review. Overall, the feedback on the mailing lists is positive.

In Objective-C, pointers (whether to objects or to a non-object type) can be marked as nullable or nonnull, depending on whether the pointer value can ever be null. In Swift, however, there is no such way to make this distinction for pointers to non-object types: an UnsafePointer<Int> might be null, or it might never be. We already have a way to describe this: Optionals. This proposal makes UnsafePointer<Int> represent a non-nullable pointer, and UnsafePointer<Int>? a nullable pointer.

Chris Willmore’s proposal, SE-0054: Abolish ImplicitlyUnwrappedOptional type, is now under review. So far feedback is mixed but mostly positive.

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.

Chris Lattner’s proposal, SE-0049: Move @noescape and @autoclosure to be type attributes, is now under review. “This proposal suggests moving the existing @noescape and @autoclosure attributes from being declaration attributes on a parameter to being type attributes. This improves consistency and reduces redundancy within the language…”

Mailing lists

The bikeshedding on proposal SE-0025: Scoped Level Access that began last week has continued. Ilya Belenkiy has updated the proposal with the feedback so far. It looks like the current set of keywords is: public, moduleprivate, fileprivate, and private. Look at that — the names are so clear that I don’t even have to explain them. 😄 However, there are concerns on the list about moduleprivate. I have to admit, I do like internal better. Chris Lattner suggests yet another option: public, internal, fileprivate, private. This sounds perfect to me. 👍

Dave Abrahams posted an update on the naming guidelines for SetAlgebra for Swift 3. You can find a draft here.

Ankit Aggarwal started a thread with a draft proposal for adding development packages as dependencies in SPM. It looks like Max Howell supports the idea.

Philippe Hausler announced that he’s pushed an initial implementation of NSOperationQueue, NSOperation and NSBlockOperation. “It is worth noting that this implementation has a few behavioral differences between this implementation and the one implemented in Objective-C. Part of this difference is due to features like QoS not being cross platform portable or KVO not yet implementable in Swift. This is very much a work-in-progress; it needs unit tests and and a bit more polish, but hopefully it is good enough to get some work started in some other places.” Great to see this progress!

Joe Groff pitched an idea on enforcing the argument order for defaulted parameters. The feedback so far is mixed, but leaning slightly in favor of enforcing the argument order.

Many people are surprised when they find out defaulted parameters can be reordered, unlike required arguments. This special case adds complexity to the language, and runs against our general trend of treating argument labels as a significant part of an API’s name, and preferring a single way of writing API calls. I think it’s worth revisiting this design choice—is the special case worth the complexity? How many people take advantage of default argument reordering?

Finally

And finally — I guess we know Kanye’s take on implicitly unwrapped optional now. 😂