Were any of you lucky enough to get a ticket to WWDC 2016?! I’m excited to share that I’ll be attending this year. If you got a ticket too, I’ll see you there! However, if you won’t be at WWDC, don’t worry. There are plenty of other great conferences. 😄 Swift Summit has announced its 2016 conference in San Francisco. It will be held this year on November 7 and 8, and yours truly will be speaking. 🤓 Also, the LLVM Developers’ Meeting will be held on November 3 and 4 in San Jose, CA.

Starter tasks

• SR-1340: [Compiler] Implement SE-0068, Expanding Swift Self to class members and value types. See the Accepted proposals section below for more details.
• SR-1327: [Compiler] Using dynamicType on a force unwrapped nil value type doesn’t throw an exception.
• SR-1304: [SwiftPM] Handle spaces in path when parsing flags from pkgconfig

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

Commits and pull requests

A few more issues have been added to the still-open Swift 2.2.x milestone on GitHub. My guess is that Xcode 7.3.1 will include these additional fixes.

Jordan Rose added a fix-it for non-optional bindings initialized with nil.

Bouke Haarsma opened a pull request with initial work for SR-1005, porting SwiftPM to use corelibs-foundation and remove the POSIX module.

Joe Groff enabled the importing of Objective-C lightweight generic type parameters into Swift as generic classes.

@codestergit opened a pull request to improve MutableCollectionType.sort, MutableCollectionType.sortInPlace and other sort related functions to take a throwing closure.

Mike Griepentrog merged a pull request with an initial implementation of NSURLCredential.

Javier Soto merged a pull request that adds tests for UnsafePointer and UnsafeMutablePointer conformance to Comparable. 👏 (SR-1238)

Dave Abrahams merged the implementation of SE-0065. 🙌 (More information below under Accepted proposals.) And Dmitri Gribenko merged the necessary changes to Swift Package Manager.

David Grove opened a pull request to implement basic usage of the _ObjectiveCBridgeable protocol on Linux. 🙇

Joe Groff fixed a leak when a bridgeable value type is dynamically cast to a class type, and the cast fails.

Chris Bailey opened a pull request to further integrate corelibs-libdispatch into corelibs-foundation. 😎

Joe Groff merged a fix for SR-613, a mis-compile that caused an over-release of “self” when partially applying a protocol method to a generic or existential of a refined class-constrained protocol.

Dave Abrahams opened a preliminary pull request for the new Set algebra APIs, ready to be merged once the Swift evolution review is complete.

Daniel Dunbar merged changes to SwiftPM to improve the portability of generated Xcode projects.

Lukas Schmidt merged a pull request with some minor refinements to NSDictionary, removing nested if let statements. It definitely makes this code more readable. 👌 Don’t forget, small wins like this are everywhere, just waiting to be discovered!

Accepted proposals

The proposal from Dmitri Gribenko, Dave Abrahams, and Maxim Moiseev, SE-0065: A New Model for Collections and Indices has been accepted! 🎉

This proposal received a significant amount of positive feedback - many people appreciated the clarification to the model, and the fact that it allows for significantly better performance in some cases as well as much simpler model in many ways. The majority of the feedback and discussion was around the specific names used in various methods. The authors of the proposal incorporated that into the latest version of the proposal (v5) which is available at the URL above.

Thank you to Dmitri Gribenko, Dave Abrahams, Maxim Moiseev and many others for contributing to the proposal, discussing the ideas, as well as to everyone else involved in the massive (ongoing) implementation effort to land this change.

Erica Sadun’s proposal, SE-0068: Expanding Swift Self to class members and value types, has been accepted — or, at least a subset of the proposal has been accepted.

This proposal had light discussion in the community review process, but the core team heavily debated it. It includes two pieces:

1. Expanding the existing support for Self to work in value types, and in the bodies of classes.
2. Replacing the x.dynamicType expression with x.Self, a purely syntactic change that eliminates the dynamicType keyword.

The core team has accepted the first half for this proposal. This allows the use of “Self” as shorthand for referring to the containing type (in the case of structs, enums, and final class) or the dynamic type (in the case of non-final classes). Most of the discussion in the core team centered around whether people familiar with the former behavior would be surprised by the (more general) behavior when using it in a class, but they came to agree that this is actually a simple and general model, and a helpful point of consistency.

In contrast, there are still a number of concerns with re-branding x.dynamicType as x.Self. This may (or may not) be the right ultimate direction to go, but it should be split out of this proposal. There is another outstanding proposal that would eliminate the Type.self syntax as being necessary, and the core team would like to resolve that discussion before tackling x.dynamicType.

Thank you to Erica Sadun for proposing this! I filed SR-1340 to track implementation work for this, this would be a great starter project for someone interested in getting involved in the Swift compiler.

Proposals in review

Doug Gregor’s proposal, SE-0070: Make Optional Requirements Objective-C-only, is under review.

Swift currently has support for “optional” requirements in Objective-C protocols, to match with the corresponding feature of Objective-C. We don’t want to make optional requirements a feature of Swift protocols, nor can we completely eliminate the notion of the language. Therefore, to prevent confusion about our direction, this proposal requires an explicit @objc attribute on each optional requirement to indicate that this is an Objective-C compatibility feature.

Tony Parker’s proposal, SE-0069: Mutability and Foundation Value Types, is under review. There is overwhelmingly positive support for this proposal from the community.

When certain Foundation types are imported into Swift, they do not fully take advantage of the features that Swift has to offer developers for controlling mutability of their objects.

This proposal describes a straightforward concept for providing this capability. It describes a set of new Foundation value types which wrap their corresponding reference types. This is a technique used by the standard library. This allows us to:

1. Improve the developer experience,
2. Increase performance for small types like Date
3. Preserving the ability for developers to customize the behavior of most types.

Regarding the performance of these changes:

In microbenchmarks designed to test access time for Date.timeIntervalSinceReferenceDate, the Swift struct consistently performed about 15% faster. […]

In microbenchmarks designed to test mutation for a new Date.addTimeInterval versus creating new NSDate objects with dateByAddingTimeInterval, the mutation approach was consistently about 40 times faster. […]

The review period has been extended for Stephen Canon’s proposal, SE-0067: Enhanced Floating Point Protocols. “Steve opted to revise his original proposal in order to incorporate great feedback from the original review period. As such, we’re extending the review period in order to get adequate consideration of his new changes.”

Doug Gregor’s proposal, SE-0071: Allow (most) keywords in member references, is under review. I recently ran into this issue trying to add a case default enum. So far, there’s positive feedback for this proposal. 🙌

The Swift API Design Guidelines consider enum cases as values that use the lowerCamelCase naming conventions. This means that case names that previously did not conflict with keywords (such as Default, Private, Repeat) now cause conflicts, a problem that is particularly acute when the naming conventions are applied by the Clang importer (per SE-0005). To mitigate this issue, this proposal allows the use of most keywords after a “.”, similarly to how SE-0001 allows keywords are argument labels.

Chris Lattner’s proposal, SE-0066: Standardize function type argument syntax to require parentheses, is now under review.

Function types in Swift use parentheses around their parameter list (aligning with the function declaration syntax, as well as the syntax used to call a function). However, in the degenerate case of a single non-variadic, unlabeled argument with no attributes, Swift allows the parentheses to be omitted. While this saves some parentheses, it introduces some minor problems, is not consistent with other parts of the Swift grammar, reduces consistency within function types themselves, and offers no additional expressive capability.

For example (Int) -> Float could be written as Int -> Float instead. This proposal would eliminate the latter. This is another great refinement to the language. These proposals that focus on consistency make me really happy. 😊

Joe Pamer’s proposal, SE-0072: Fully eliminate implicit bridging conversions from Swift, is under review. So far, there’s very little feedback from the community.

In Swift 1.2, we attempted to remove all implicit bridging conversions from the language. Unfortunately, problems with how the v1.2 compiler imported various un-annotated Objective-C APIs caused us to scale back on our ambitions. In the interest of further simplifying our type system and our user model, we would like to complete this work and fully remove implicit bridging conversions from the language in Swift 3.

Mailing lists

Tony Parker introduced his proposal on Mutability and Foundation Value Types. As mentioned above, this is currently under review.

Dear swift-evolution denizens,

As you know from our announcement of Swift Open Source and our work on naming guidelines, one of our goals for Swift 3 is to “drop NS” for Foundation. We want to to make the cross-platform Foundation API that is available as part of swift-corelibs feel like it is not tied to just Darwin targets. We also want to reinforce the idea that new Foundation API must fit in with the language, standard library, and the rapidly evolving design patterns we see in the community.

You challenged us on one part of this plan: some Foundation API just doesn’t “feel Swifty”, and a large part of the reason why is that it often does not have the same value type behavior as other Swift types. We took this feedback seriously, and I would like to share with you the start of an important journey for some of the most commonly used APIs on all of our platforms: adopting value semantics for key Foundation types.

John Holdsworth revived a previous discussion on adding multi-line string literals to Swift and even prepared a pull request with an initial implementation. There seems to be a decent amount of interest from the community and Chris Lattner provided a lot of feedback on the idea.

Honza Dvorsky started a thread about adding an option to SwiftPM to dump a package’s dependency tree. Daniel Dunbar supports the idea. I think this would be pretty cool. 😎

Erica Sadun pitched an idea on requiring proactive overrides for default protocol implementations. She proposes requiring the override in cases where a class implements a protocol method that is already defined on a protocol extension. Doug Gregor opposes the idea.

Finally

And finally — from reddit post to fix in less than 12 hours, Joe Pamer pushes a fix to “sober up” the drunken Swift compiler. 😂 (Hacker News, reddit)