More proposals are making it through the review process this week as “phase 2” discussions of the Swift 4 development cycle come to a close, most notably SE-0168 and SE-0169. Proposal SE-0168 would add support for (highly desired!) multi-line String literals. No longer would we be forced to resort to string concatenation like animals. Proposal SE-0169 is a follow-up to the rejection of SE-0159 and seems to be our last hope for modifying access control in Swift, or repairing it depending on your perspective. There is a light at the end of the access control tunnel! Or maybe those are the headlights of an oncoming train, not sure. 😆

Swift Unwrapped

Episode 6: Swift 3.1 Release & SwiftPM Improvements

This week we discuss our thoughts on the Swift 3.1 release and the Swift Package Manager improvements that came with it!

News and community

Ted Kremenek announced that an official ABI dashboard is now available on Swift.org.

One of the top priorities for Swift right now is compatibility across future Swift versions. One major component of this is ABI stability, which enables binary compatibility between applications and libraries compiled with different versions of Swift.

From Ted:

The tasks currently tracked on the dashboard are fairly low-level details concerning the ABI itself. These include details that should be re-reviewed and finalized, or finishing up areas we know are incomplete.

Toni Suter is working on cross-platform Swift IDE called Tifig. It looks like its still in the very early stages, but worth checking out and keeping an eye on. 😎 “Tifig is a Swiss German word and means ‘swift’.”

Should you file a radar or open a JIRA task for bugs you find? It’s not always clear. Filing bugs in JIRA for Swift is pretty painless, but radar is awful. This week Keith Smiley announced a new macOS app for radar, Brisk.

Commits and pull requests

Mark Lacey is working on something really cool to solve a large class of “expression too complex” issues. (h/t Slava Pestov)

Michael Ilseman merged a pull request for the “unicode rethink” branch that results in a 3x speedup for small strings by “exploding” the code units, that is, by making a fixed-size array and unpacking into it.

Slava Pestov started implementing preliminary Sema and AST support for subclass existentials for SE-0156.

Doug Gregor finished the implementation of SE-0160.

Accepted proposals

SE-0160: Limiting @objc inference was accepted.

The feedback on the second round of review was very light and uniformly positive.

The proposal has been implemented in #8379. Early experience migrating a nontrivial Cocoa app (~200k LOC, roughly half Swift and half Objective-C) resulted in a 5.7% decrease in code size (Release build) and required only 40 new @objc annotations, 37 of which were indicated by the new compiler warnings, 2 of which manifested as post-migration errors, and the last of which was found with the new (opt-in) runtime warnings.

Thank you to Doug Gregor for the proposal, and also the implementation of this improvement!

SE-0162: Package Manager Custom Target Layouts was accepted (and implemented!).

The feedback we received prior to and during the review was very positive.

Thanks to everyone who participated!

Proposals in review

SE-0166: Swift Archival & Serialization by Itai Ferber, Michael LeHew, and Tony Parker is under review.

Foundation’s current archival and serialization APIs (NSCoding, NSJSONSerialization, NSPropertyListSerialization, etc.), while fitting for the dynamism of Objective-C, do not always map optimally into Swift. This document lays out the design of an updated API that improves the developer experience of performing archival and serialization in Swift.

Specifically:

• It aims to provide a solution for the archival of Swift struct and enum types
• It aims to provide a more type-safe solution for serializing to external formats, such as JSON and plist

The primary motivation for this proposal is the inclusion of native Swift enum and struct types in archival and serialization.

SE-0167: Swift Encoders by Itai Ferber, Michael LeHew, and Tony Parker is under review.

As part of the proposal for a Swift archival and serialization API (SE-0166), we are also proposing new API for specific new encoders and decoders, as well as introducing support for new Codable types in NSKeyedArchiver and NSKeyedUnarchiver.

This proposal composes the latter two stages laid out in SE-0166.

With the base API discussed in SE-0166, we want to provide new encoders for consumers of this API, as well as provide a consistent story for bridging this new API with our existing NSCoding implementations. We would like to offer a base level of support that users can depend on, and set a pattern that third parties can follow in implementing and extending their own encoders.

SE-0168: Multi-Line String Literals by John Holdsworth, Brent Royal-Gordon, and Tyler Cloutier is under review.

This proposal introduces multi-line string literals to Swift source code. This has been discussed a few times on swift-evolution most recently putting forward a number of different syntaxes that could achieve this goal each of which has their own use case and constituency for discussion.

Multi-line String literals are a common programming-language feature that is, to date, still missing in Swift. Whether generating XML/JSON messages or building usage messages in Swift scripts, providing string literals that extend over multiple lines offers a simple way to represent text without having to manually break lines using string concatenation. Concatenation is ungainly and may result in slow compilation.

SE-0169: Improve Interaction Between private Declarations and Extensions by David Hart and Chris Lattner is under review.

In Swift 3, a declaration marked private may be accessed by anything nested in the scope of the private declaration, for example a private property or method defined on a struct may be accessed by methods defined within that struct.

This model was introduced by SE-0025 and with nearly a year of experience using this model, it has worked well in almost all cases. The primary case it falls down is when the implementation of a type is split into a base definition and a set of extensions. Because of the SE-0025 model, extensions to the type are not allowed to access private members defined on that type.

This proposal recommends extending private access control so that members defined in an extension of a type have the same access as members defined on the type itself, so long as the type and extension are in the same source file. We expect this to dramatically reduce the number of uses of fileprivate in practice.

Mailing lists

Project Lead Ted Kremenek sent out an email regarding Swift 4, phase 2:

In mid-February we kicked of “stage 2” for the discussion of evolution proposals for Swift 4.

The timetable set forth was to have discussions for “stage 2” go through April 1. The intent of that timetable was to (a) timebox discussions on proposals to help focus them within the theme/focus areas of the release and to (b) provide time after discussion to implement approved proposals for Swift 4.

While the April 1 date for the end of stage 2 has passed, it is clear that by looking at where we are in the development of Swift 4 and what remains to be done that there are still important discussions happening on swift-evolution concerning changes possibly impacting Swift 4. Those discussions should continue and given the opportunity to converge. That said, we have reached to point where we need to be increasingly circumspect on what topics remain in scope for Swift 4.

At this point, discussions about changes impacting Swift 4 should generally focus in the following areas:

Anything fitting in the “stage 1” phase for the release, such as (among others) the String re-evaluation and the memory ownership model remain priority topics to discuss.

Existing topics we have already covered during “stage 2” also remain relevant to discuss for the release, although the scope of actual change we will consider for Swift 4 is rapidly diminishing. The distinction of what is “out-of-scope” may not always be clear to everyone, and the Core Team will try and provide clear guidance as discussions happen on swift-evolution where appropriate to indicate whether or not something is in scope for Swift 4.

Looking beyond Swift 4, serious discussion about Swift 5 will likely start up in July as the themes and focus areas of that release are identified.

Thank you to everyone who has contributed to the discussions so far to help shape Swift 4!

Finally

And finally — a new access control proposal. 😂 It’s funny because it’s true. 😅