The biggest news over the past week (and likely disappointing for some) was that ABI stability has been deferred from Swift 4. In practice, ABI stability likely affects very few Swift users directly, and for those whom are affected it would be much worse to lockdown the ABI too soon rather than delay it further. In a sense, that leaves ABI stability as mostly a symbol of Swift’s maturity (or lack thereof). Aside from the obvious impacts of those affected by the lack of ABI stability, the major impact here is that iOS developers will continue to be required to bundle the Swift standard library with their apps. This is also a blocker for wider adoption of Swift within Apple (including eventually providing Swift-only APIs in the SDKs).

While inconvenient, this is not the end of the world. The Core Team is clearly dedicated to declaring ABI stability as soon as they reasonably can, and will continue working toward this goal during the remainder of the Swift 4 release cycle. Having said that, I think if there are delays for this beyond Swift 5, that’s when the community should begin to worry. In other news, a new manifesto on memory ownership landed this week and Slava fixed an 18-month-old radar! 😄

Starter tasks

In Ted Kremenek’s Swift 4, stage 2 announcement, he mentioned some starter proposals. There’s probably two dozen or so JIRA tasks that describe these potential proposals and they vary in complexity and difficulty. You should definitely have a look if you’re interested in writing a proposal. Checkout the list and see if there’s a task for a feature you’ve been wanting. Remember, proposals can have multiple authors — so don’t hesitate to collaborate with others.

The Core Team has also identified some starter proposals that fit well with the goals of Swift 4. Taking one of those ideas and developing it into a complete proposal is a fantastic way to get involved in the Swift evolution process.

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

News and community

Ted Kremenek wrote an official blog post on the Swift 4 Release Process, describing the goals, release process, estimated schedule, and how source compatibility will work between Swift 3 and 4.

Károly Lőrentey (@lorentey) posted a series of tweets on the performance of Set and Array.

Fun Swift quiz: given a large Array<Int> with random values, which of these two is faster?

1. array.sorted()
2. Set<Int>(array)

Xcode 8.3 beta 3 was released.

Commits and pull requests

Doug Gregor (@dgregor79) fixed an issue in the constraint solver to now handle disjunctions as separate connected components. The pull request description is fantastic and worth a read. (See also: tweet.)

Graydon Hoare (@graydon) unfortunately had to revert enabling bridging PCH by default due to some concerns regarding source compatibility. This feature is now opt-in rather than opt-out. This was the subject of his blog post last month, Faster Mix-and-Match Builds with Precompiled Bridging Headers. Unfortunately, disabling this feature means regressing build times for users who may not realize they will need to enable this manually.

Slava Pestov (@slava_pestov) merged preliminary Sema support for generic subscripts, building upon a number of previous pull requests. He notes that this also fixes an 18-month SourceKit radar. See — radars do get fixed in a timely manner! 😉

Michael Gottesman (@gottesmm) merged changes to completely refactor class constructor initialization for ownership, fixing a number issues with the previous implementation.

Hugh Bellamy (@hughbe) ported swiftSyntax to Windows.

@ddunn2 opened a pull request with an initial implementation of ByteCountFormatter.

Slava Pestov addressed a couple of ABI FIXMEs by deleting code.

Doug Gregor (@dgregor79) committed notes on Swift’s stage 2 goals and priorities.

Returned proposals

SE-0155: Normalize Enum Case Representation by Daniel Duan and Joe Groff was reviewed briefly and returned for revision early.

From the proposal:

In Swift 3, associated values for an enum case are represented by a labeled-tuple. This has several undesired effects: inconsistency in enum value construction syntax, many forms of pattern matching, missing features such as specifying default value and missed opportunity for layout improvements.

This proposal aims to make enums more “regular” by replacing tuple as the representation of associated values, making declaration and construction of enum cases more function-like.

John McCall:

The core team met and talked about SE-0155 today, even though we’re not quite done with the review period, and here’s where we stand.

SE-0155 is being returned for revision. Consensus appears to be strongly in favor of requiring argument labels (if provided) to be enforced on “call” sites. However, the core team feels that the proposal needs revision in the following ways:

• Are internal argument names syntactically allowed in a case declaration?
• Can cases with the same base name be overloaded by argument label? If so, is a pattern match using just the bare name ambiguous or does it match both cases?
• Can cases with the same name (using the same rule as above) be overloaded by argument type? If so, how are they disambiguated in pattern matches?
• Do pattern matches require argument labels to be given along with value patterns, e.g. “case .valid(value: let value)”, or is there some way to shorten this? If the latter, what are the rules for that?
• Are you proposing anonymous cases, and if so, what are the language rules for them?
• The proposal makes a claim about layout efficiency; please either discuss this claim or remove it.

Proposals in review

SE-0153: Compensate for the inconsistency of @NSCopying’s behaviour by Torin Kwok is under review.

First of all, in Swift, the Objective-C copy property attribute translates to @NSCopying.

Like Objective-C, in Swift, avoiding accessing ivar via setter methods in initializer is considered as the best pratice. Unlike Objective-C, which gives developers the freedom to decide on whether assign a value to a property by invoking setter or by accessing ivar directly, accessing a property in Swift from within an initializer always does direct access to the storage rather than going through the setter, even if using dot syntax.

However, as a side-effect, @NSCopying attribute does not work as consistently as we usually expected in Swift initializers after developers declared a property as @NSCopying.

[…]

SE-0154: Provide Custom Collections for Dictionary Keys and Values by Nate Cook is under review.

This proposal addresses significant unexpected performance gaps when using dictionaries. It introduces type-specific collections for a Dictionary instance’s keys and values properties.

New collection types provide efficient key lookup and mutable access to dictionary values, allowing in-place updates and copy-on-write optimization of stored values. The addition of these new types impacts the standard library ABI, since we won’t be able to use types aliases from the existing types for keys and values. […]

SE-0104: Protocol-oriented integers is under review for the third (and final? 😅) time. This proposal was accepted for Swift 3, but was not implemented in time.

This proposal cleans up Swifts integer APIs and makes them more useful for generic programming.

The language has evolved in ways that affect integers APIs since the time the original proposal was approved for Swift 3. We also attempted to implement the proposed model in the standard library and found that some essential APIs were missing, whereas others could be safely removed.

Swift’s integer protocols don’t currently provide a suitable basis for generic programming. See this blog post for an example of an attempt to implement a generic algorithm over integers.

[…]

Mailing lists

Ted Kremenek announced Swift 4, stage 2:

Back in July, we laid out a plan for Swift 4 which divided the release into two stages. Since then, we’ve been in Swift 4 stage 1 […]

Since July, we now have a much better understanding now of how to achieve ABI stability, with an ABI Manifesto detailing the list of all language/implementation work that is needed to achieve ABI stability. We have made substantial progress in that work during stage 1, but much remains to be done. Once Swift achieves ABI stability the ABI can be extended, but not changed. Thus the cost of locking down an ABI too early is quite high.

Deferring ABI Stability from Swift 4
Given the importance of getting the core ABI and the related fundamentals correct, we are going to defer the declaration of ABI stability out of Swift 4 while still focusing the majority of effort to get to the point where the ABI can be declared stable.

To allow the community to follow along with this effort, an ABI dashboard will get wired up from the swift-evolution home page that will present a table of main ABI tasks remaining and what Swift release they landed in. This dashboard will largely track open tasks in JIRA. I expect the dashboard to be up next week, and I’ll send a follow up email when it is available.

Stage 2
With ABI stability well-understood and many of the stage 1 goals underway, it is time to open up Swift 4 stage 2 to expand the scope of proposals to be considered.

Timeline
Stage 2 starts right now. All design work and discussion for stage 2 extends to April 1, 2017. The intent is to timebox discussion to provide adequate time for the actual implementation of accepted proposals.

Continue reading…

Ben Cohen started a discussion on Sequence and Collection enhancements for “stage 2” of Swift 4 development:

Following up on Ted’s post regarding the opening up of stage 2, I’m starting a thread to discuss additive algorithms for Sequence and Collection. Here is a list of commonly requested algorithms to operate on Sequence or Collection: […]

Please reply here with any comments or questions on the above list, or any additions you believe are important that are missing from it. As this focus area is larger in scope than Dictionary, it is likely that it will need to be broken up into multiple separate proposals. The plan is to get an initial high-level signal from this thread on which areas to put focus on. We are also looking for volunteers to put together proposals and implementations — if you’re interested in helping with that, please email me off-list. High quality community implementations will significantly improve the chances of a feature making it into Swift 4. Smaller, more focused proposals are also more likely to make it than larger ones.

Continue reading…

John McCall started a thread to introduce a new Ownership Manifesto:

Memory ownership is a topic that keeps poking its head up here. Core team members have mentioned several times that it’s something we’re interested in working on. Questions sometimes get referred back to it, saying stuff like “we’re working on tools to let you control ARC a little better”. It’s even on the short list of high-priority features for Swift 4 […]

From the manifesto introduction:

Adding “ownership” to Swift is a major feature with many benefits for programmers. This document is both a “manifesto” and a “meta-proposal” for ownership: it lays out the basic goals of the work, describes a general approach for achieving those goals, and proposes a number of specific changes and features, each of which will need to be separately discussed in a smaller and more targeted proposal. This document is intended to provide a framework for understanding the contributions of each of those changes.

It’s a lengthy read, but very interesting. If long form reading isn’t your thing, Alexis Beingessner was kind enough to write up some TL;DR notes on the manifesto.

Finally

And finally — using computers The Australian Way™. ¯\_(ツ)_/¯