This week was manifesto week, with a couple of new manifestos showing up in the main Swift repo a la Doug Gregor’s original Generics Manifesto. Additional interviews with Chris Lattner made their rounds on the web, and the first few proposals of the new year are under review — evidence that Boris Bügling does actually work sometimes. 😉 😄

Interested in sponsoring Swift Weekly Brief? Learn more here.

News and community

Mishal Shah announced that Swift 3.1 development snapshots are now available on Swift.org.

The first Xcode 8.3 beta was released. This version no longer supports Swift 2.3 and includes Swift 3.1 which is intended to be source compatible with Swift 3.0.

In case you haven’t read and listened to enough interviews with Chris Lattner 😄, Slashdot posted an interview, Accidental Tech posted a full transcript of their interview from last week, and Chris also appeared on the SwiftCoders podcast. 😎

Let Greg Heo (@gregheo) take you on a tour of .map in Swift. If you’ve had trouble understanding what .map does and how it works, then read this article and thank Greg later.

Jacob Bandes-Storch (@jtbandes) noticed that Swift syntax highlighting changes have been pushed to GitHub.

Not new (but new to me!), but Caleb Davenport (@calebd) pointed out that there’s unofficial Swift docs hosted at fossies.org. You can type in the name of any class in the Swift compiler C++ source code and it will show you class diagrams, documentation, and more. From Greg Heo: “I looked up what I thought would make the scariest class diagram and wasn’t disappointed.” See VisitNodeResult. 😅

Commits and pull requests

Ben Cohen (@airspeedswift) committed a new doc, the String Manifesto:

For Swift 4 and beyond we want to improve three dimensions of text processing:

1. Ergonomics
2. Correctness
3. Performance

This document is meant to both provide a sense of the long-term vision (including undecided issues and possible approaches), and to define the scope of work that could be done in the Swift 4 timeframe. […]

Michael Ilseman (@milseman) committed a new doc, the Swift ABI Stability Manifesto:

One of the top priorities for Swift right now is compatibility across future Swift versions. Compatibility aims at accomplishing two goals:

1. Source compatibility means that newer compilers can compile code written in an older version of Swift. This aims to reduce the migration pain that Swift developers face when migrating to a newer Swift version. […]
2. Binary framework & runtime compatibility enables the distribution of frameworks in a binary form that works across multiple Swift versions. […]

This document is an exploration and explanation of Swift’s ABI alongside the goals and investigations needed before declaring Swift’s ABI stable. It is meant to be a resource to the community as well as a declaration of the direction of Swift’s ABI. […]

Tony Allevato (@allevato) merged improvements to speed up Character.init, resulting in a ~150-300x improvement in some scenarios. 😱 The pull request description has all of the details.

Jacob Bandes-Storch (@jtbandes) has been working on improving the new proposal status page.

Michael Gottesman (@gottesmm) merged ownership verifier fixes that were found when testing the verifier on SILGen output.

@larryonoff merged support for watchOS, tvOS, and iOS in corelibs-xctest.

David Grove (@dgrove-oss) implemented pthread_workqueue within libdispatch.

There’s an old, but really interesting pull request from Brian Croom (@briancroom) that adds unit testing infrastructure to corelibs-xctest. It still hasn’t been merged, but maybe someone out there is interested in nudging it along. 😄

Proposals in review

Proposal SE-0148: Generic Subscripts by Chris Eidhof is under review.

Currently, subscripts can’t be generic. This is limiting in a number of ways:

• Some subscripts are very specific and could be made more generic.
• Some generic methods would feel more natural as a subscript, but currently can’t be. This also makes it impossible to use them as lvalues. This feature is also mentioned in the generics manifesto under generic subscripts.

Example of a generic subscript:

extension Collection {
  subscript<Indices: Sequence>(indices: Indices) -> [Iterator.Element] where Indices.Iterator.Element == Index {
    // ...
  }
}

Or a generic return type:

extension JSON {
  subscript<T: JSONConvertible>(key: String) -> T? {
    // ...
  }
}

Proposal SE-0149: Package Manager Support for Top of Tree development by Boris Bügling (#yatusabes) is under review.

This proposal adds enhancements to swift package edit to support development of packages without strict versioning (“top of tree” development).

The package manager currently supports package dependencies which are strictly versioned according to semantic versioning. This works well for users of packages and it is possible to edit a package in place using swift package edit already, but we want to allow developers to manually check out repositories on their machines as overrides. This is useful when developing multiple packages in tandem or when working on packages alongside an application. […]

Proposal SE-0150: Package Manager Support for branches by Boris Bügling (#yatusabes) is under review.

This proposal adds enhancements to the package manifest to support development of packages without strict versioning. This is one of two features, along with “Package Manager Support for Top of Tree development”, being proposed to enable use of SwiftPM to develop on “top of tree” of related packages.

The package manager currently supports packages dependencies which are strictly versioned according to semantic versioning. This is how a package’s dependencies should be specified when that package is released, but this requirement hinders some development workflows:

• bootstrapping a new package which does not yet have a version at all
• developing related packages in tandem in between releases, when one package may depend on the latest revision of another, which has not yet been tagged for release

[…]

Mailing lists

Rick Ballard sent an email announcing the Swift 4 Package Manager roadmap. This lengthy email is worth a read and shows how hard the SwiftPM team has been working. Features and improvements that will ship with Swift 3.1 include: a new swift package edit command to begin editing on a package, pinning, project generation improvements, a new dependency resolver, cycle detection and incremental build correctness, parallel cloning, and improved test coverage and infrastructure. The work that the team is planning for Swift 4 is even more impressive.

Hello Swift Package Manager community,

The package manager’s release in Swift 3 was a big success, with many enthusiastic adopters. Since then we’ve been hard at work building the next version of the package manager. We have a lot we want to do, but focus is important for building a successful tool, so we’ve defined a set of goals that we expect to focus on for Swift 4. As always, this roadmap may be amended based on feedback from the community, and pull requests for improvements outside this list are still welcome!

This email covers a lot of different features, so instead of replying directly it would be best to start a new thread on any topic you’d like to discuss in detail.

Continue reading…

Thomas Catterall (@swizzlr) announced an unofficial “official” docker container for Swift.

I’m pleased to announce that with the assistance of many, many people (see below), we have released an “official” Docker image for Swift.

The image contains everything needed to compile and run a Swift application, reliably and reproducibly. It’s based on Ubuntu 16.04 and has been used in production for many months now. A Docker library image such as this one occupies the top level namespace, so that you can simply write “FROM swift” to refer to the image. It has received extensive auditing for best practices and security by Docker experts, and will be maintained by a dedicated team of volunteers.

I would like to encourage everyone interested to ask questions and offer improvements over on the Github repo. […]

In LLVM Weekly #160 Alex Bradbury linked to an email from John Regehr, the secretary of the LLVM Foundation, that announced that Chris Lattner will remain on the LLVM Foundation Board of Directors.

As you’ve likely heard by now, Chris Lattner is leaving his position at Apple, and thus will no longer be managing Apple’s LLVM efforts. This raised a question of whether Chris should be removed from the LLVM Foundation Board of Directors. After discussing the issue, the board unanimously agreed that there is no reason to change the board’s composition, or anything else related to the Foundation’s governance, at this time. […]

Also on the LLVM-dev lists, Alex Rosenberg reiterated Apple’s commitment to LLVM:

You may have heard about changes in the Swift community, and we wanted to make it clear that Apple is strongly committed to open source and the LLVM and Clang tools.

Our compiler toolchain has been, is, and will continue to be based on LLVM and Clang. We remain one of the largest users of and contributors to LLVM, as evidenced by our extensive contributions to the project and the breadth of Apple employee participation in the overall project and the LLVM DevMtg in November. We’re as committed as ever.

Tony Parker asked for help in testing URLSession:

As we’re wrapping up Swift 3.1, I think it’d be a great opportunity to have a quality focus area on one of our most important APIs: URLSession. If you’ve been wondering how to make a meaningful contribution, this is the perfect time.

It’d be great to greatly expand both unit test and higher level test coverage of URLSession. For testing that can’t really be part of a unit test and CI like poorly performing networks or esoteric configurations, it would also be nice to build a different kind of test tool. That tool would provide a lot of knobs for controlling a URLSession. We could make this tool part of the swift-corelibs-foundation project.

Is anyone interested in chipping in here? We don’t have to start big. Even small contributions could get us moving in the right direction.

Finally

And finally — “This program cannot be run in DOS mode.”