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. 😁
- SR-1112: Wrong suggestion by Fix-it for
if letunused vars
- SR-1022: Missing “unused result” warning for
- SR-1005: SwiftPM port to Foundation
- SR-1111: Non-optimized builds should avoid redundant
- SR-1115: Adding initializers to
UIntto convert from
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.
Mike Griepentrog opened a pull request for an initial implementation of
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
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
Nate Cook merged a pull request that makes
Array’s conformance to
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.” 🙌
Chris Bailey implemented a missing
NSString initializer in corelibs-foundation:
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.
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
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
UInt to convert from
UnsafeMutablePointer, has been accepted for Swift 3. “This rounds out a missing aspect of our unsafe pointer APIs. Where it was possible to convert
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. 😄
In Objective-C, pointers (whether to objects or to a non-object type) can be marked as
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.
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
@autoclosure to be type attributes, is now under review. “This proposal suggests moving the existing
@autoclosure attributes from being declaration attributes on a parameter to being type attributes. This improves consistency and reduces redundancy within the language…”
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:
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:
private. This sounds perfect to me. 👍
Philippe Hausler announced that he’s pushed an initial implementation of
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?
And finally — I guess we know Kanye’s take on implicitly unwrapped optional now. 😂