This week Ted Kremenek wrote an official blog post on the Swift 3.0 release process. It’s going to be an exciting release and it’s still scheduled to ship later this year. Unfortunately, it won’t be ready by WWDC 2016, but I’m sure we’ll have a decent beta by then.

The main Swift repository also surpassed 30,000 stars this week! That’s nearly double the amount of the next most popular programming language developed on GitHub. ⭐️⭐️⭐️ Here’s to an amazing community — Swift certainly is more than a programming language. 😊

Starter tasks

For recently accepted proposals:

• SR-1489: Implement support for SE-0060, enforcing order of defaulted parameters.
• SR-1490: Implement SE-0076 by changing some UnsafeMutablePointer taking methods to take UnsafePointer instead.
• SR-1491: Implement support for SE-0080, failable Numeric Conversion Initializers

From Danuel Duan:

• SR-1469: Diagnostic for init? is reported at the end of the method despite an early return.

From Brian Gesiak:

• SR-1421: Document the sourcekitd-test tool, which is used to quickly experiment with SourceKit. This task will involve writing a small amount of C++. You’ll learn about LLVM’s command line interface library and its argument parser, as well as about Swift’s SourceKit.

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

Commits and pull requests

Bhargav Gurlanka merged adding a JSON dumper for dependencies in SPM.

Brian Croom opened a pull request on corelibs-xctest to add the XCTest performance measurement APIs.

PJ Gray merged adding support for ARMv6 on linux in corelibs-foundation.

Alex Hoppen implemented proposal SE-0036: Requiring Leading Dot Prefixes for Enum Instance Member Implementations.

Nate Cook merged revisions to the documentation for core types and protocols.

Trent Nadeau opened a pull request to use @discardableResult and warn by default, as part of the effort to complete SE-0047.

Slava Pestov implemented closure reflection. (Note the pull request was closed, but the commits were merged manually.)

Russ Bishop implemented proposal SE-008: Add a Lazy flatMap for Sequences of Optionals.

Michael Ilseman merged CoreGraphics API naming changes for the latest API naming guidelines.

Joe Pamer implemented his proposal, SE-0072: Fully eliminate implicit bridging conversions from Swift. (Note: it was reverted, then the revert was reverted. Yo dawg, I heard you like reverts. 😄)

Jordan Rose merged changes to allow importing pointer-returning methods as throwing.

Jorge Bernal implemented proposal SE-0070: Make Optional Requirements Objective-C-only.

Congratulations to Ankit Aggarwal for becoming the #2 contributor on Swift package manager. 👏

Accepted proposals

Joe Pamer’s proposal, SE-0072: Fully eliminate implicit bridging conversions from Swift, was accepted for Swift 3.

The feedback on this proposal was positive - the benefits of simplifying the type system and eliminating surprising behavior from the compiler is universally appealing. However, both the core team and the community wanted a better sense of what the impact of the proposal would be in practice on real code. Joe Pamer did some analysis and found out that there isn’t a significant impact on the most concerning use case.

Chris Lattner’s proposal, SE-0066: Standardize function type argument syntax to require parentheses, was accepted for Swift 3.

There was a significant amount of feedback on the proposal, with a fairly common theme of “lukewarm acceptance.” A number of community members were sad to see this familiar syntactic shortcut go away, but acknowledge that it fits well with recent directions, e.g., the elimination of the implicit tuple splat behavior SE-0029. The core team acknowledges that the ability to elide parentheses is not actively harmful to the language, but felt that it was better to have consistency around function types (always have parentheses) than provide a relatively small syntactic shortcut for higher-order functions. The core team did not feel that this proposal needed to include required parentheses within closures, which have their own fairly specific grammar.

Joe Groff’s proposal, SE-0060: Enforcing order of defaulted parameters, was accepted for Swift 3.

The feedback on the proposal was generally positive (several people remarked that they didn’t know this was allowed). Some people pointed out that removal of this capability penalizes API design in cases where there is no inherent order to parameters, but this is also true of non-defaulted parameters. The core team prefers to encourage consistency at call sites.

Janosch Hildebrand’s proposal, SE-0076: Add overrides taking an UnsafePointer source to non-destructive copying methods on UnsafeMutablePointer, was accepted with revisions for Swift 3.

The feedback on the proposal from the community and the core team universally agreed that there is a problem that needs to be solved here. However, instead of adding overloads of the methods as proposed, it would be better to change the existing methods to take UnsafePointer<> instead of UnsafeMutablePointer<>. Given the existing promotion rules that exist in the compiler, it will achieve the same effect. As part of this, other similar functions in the standard library should be audited and fixed as well.

Matthew Johnson’s proposal, SE-0080: Failable Numeric Conversion Initializers, was accepted with revisions for Swift 3.

The feedback on the proposal from the community and the core team was universally positive, and the new initializers on the primitive integer and floating point types have been approved. However, swift-evolution isn’t the right mechanism to propose extensions to Foundation types, so the extensions that adds conversions from NSNumber and to Foundation types should be subset out of the proposal.

Rejected proposals

Proposal SE-0073: Marking closures as executing exactly once was rejected for Swift 3. Though feedback from the community and core team was positive, the proposal was reject for two main reasons. Chris Lattner notes that he would like to this discussed for a future release, beyond Swift 3.

1. The surface level syntax of @noescape needs to be reconsidered. At the minimum, we need to rename @noescape to @nonescaping for consistency with our previously agreed attribute naming scheme. However, it is also work discussing whether @nonescaping should be the default: if so, the attribute should actually become @escaping, and the functionality proposed in SE-0073 would be named @once.

2. Separate from the surface level issues, the implementation underlying this work has some significant challenges that are doable but would require major engineering work. Specifically, the definite initialization pass needs to “codegen” booleans in some cases for conditional initialization/overwrite cases, and these state values would have to be added to closure capture lists. This would require enough engineering work that it seems unlikely that it would happen in the Swift 3 timeframe […]

Proposal SE-0074: Implementation of Binary Search functions was rejected for Swift 3.

The feedback on the proposal was generally positive about the concept of adding binary search functionality, but negative about the proposal as written, with feedback that it was adding too much complexity to the API.

Proposals in review

Tony Parker’s and Philippe Hausler’s proposal, SE-0086: Drop NS Prefix in Swift Foundation, is under review. “As part of Swift 3 API Naming and the introduction of Swift Core Libraries, we are dropping the NS prefix from key Foundation types in Swift.” Note that not all types are removing the prefix, only the ones specified in the proposal. Additionally, some types will be hoisted, or lifted up into a class container as a sub-type. For example, NSCalendarUnit will become Calendar.Unit. Surprisingly, there’s only mildly positive feedback on this so far with concerns from the community about reference versus value semantics for types that will receive a value-type (struct) counterpart, as well as “inheriting” some unnecessary Objective-C legacy.

Matthew Johnson’s and Erica Sadun’s proposal, SE-0041: Updating Protocol Naming Conventions for Conversions, is under review. “We propose to expand and improve the naming conventions established by the API Guidelines and the standard library with regard to conversion related protocols. We believe common protocol naming patterns should be clear, consistent, and meaningful.” Their proposed solution includes establishing three protocol suffixes — Creatable, Convertible, and Representable — and renaming the protocols in the stdlib. So far there’s positive support from the community for bringing consistency here, but some debate about the naming of the suffixes. Programmers bikeshedding on how to name things? I know it’s hard to believe. 😄

Erica Sadun’s proposal, SE-0075: Adding a Build Configuration Import Test, is under review. Similar to using #if os(iOS), Erica proposes adding a new configuration to test if modules are available. For example, #if canImport(UIKit) would determine whether or not UIKit is supported on the current platform. Only David Hart and Xiaodi Wu have responded to this, but their feedback was positive.

Swift’s existing set of build configurations specify platform differences, not module commonalities. For example, UIKit enables you to write view code supported on both iOS and tvOS. SpriteKit allows common code to render on OS X, iOS, and tvOS that would require an alternate UI on Linux. Testing for Metal support or Media Player would guard code that will not function on the simulator. If the simulator adopted these modules at some future time, the code would naturally expand to provide compatible execution without source modification.

A proposal from David Hart, Robert Widmann, and Pry Jahkola, SE-0081: Move where clause to end of declaration, is under review. The proposal suggests moving the where clause that’s used to constrain generic type parameters to the end of the declaration syntax. The motivation here is that where clauses can get quite long, which negatively impacts readability. Erica Sadun has a great post describing the issue. So far feedback from the community is positive, although Joe Groff raises a concern about how this will affect the type grammar. Here’s an example:

// OLD
func foo<T: MyProtocol where T: Equatable>(val: T) -> Bar

// NEW
func foo<T: MyProtocol>(val: T) -> Bar where T: Equatable

Joe Groff’s proposal, SE-0083: Remove bridging conversion behavior from dynamic casts, is under review. There’s little feedback here, but it is positive.

Dynamic casts using as?, as!, and is are currently able to dynamically perform Cocoa bridging conversions, such as from String to NSString or from an ErrorProtocol-conforming type to NSError. This functionality should be removed to make dynamic cast behavior simpler, more efficient, and easier to understand.

Grant Paul’s and Erica Sadun’s proposal, SE-0084: Allow trailing commas in parameter lists and tuples, is under review. “Swift permits trailing commas after the last element in array or dictionary literal. This proposal extends that to parameters and tuples.” There’s mixed feedback from the community on this proposal. Tony Allevato and Chris Lattner argue against these changes noting the structural differences between collections, parameters lists, and tuples. Rob Napier argues the benefits of having a general rule dictating “trailing commas are allowed in comma-separated lists”.

Matt Wright’s proposal, SE-0088: Modernize libdispatch for Swift 3 naming conventions, is under review. “The existing libdispatch module imports the C API almost verbatim. To move towards a more natural Swift interface and away from the C API, this proposal outlines changes to the libdispatch module and the motivation behind them.” I was surprised to see the mixed feedback from the community here, although it is more positive than negative. Concerns centered around the proposed naming (surprise! 😄) as well as general API churn. Dan Appel had an interesting idea about introducing LibDispatch to retain the existing C APIs and Dispatch for the Swifty versions of the APIs.

Rick Ballard’s proposal, SE-0085: Package Manager Command Names, is under review. There’s overwhelmingly positive support for these changes.

This is a proposal for changing the command names used for invoking the Swift package manager. Instead of hanging all functionality off of swift build and swift test, we will introduce a new swift package command with multiple subcommands. swift build and swift test will remain as top-level commands due to their frequency of use.

Finally

And finally — mangled name or cat walking on keyboard? ⌨️ 🐈 😂