Issue #54 26 Jan 2017
Written by: Jesse Squires
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
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. 😎
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
For Swift 4 and beyond we want to improve three dimensions of text processing:
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. […]
One of the top priorities for Swift right now is compatibility across future Swift versions. Compatibility aims at accomplishing two goals:
- 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. […]
- 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. […]
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
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:
Or a generic return type:
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 editalready, 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. […]
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
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.
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. […]
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
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.
And finally — “This program cannot be run in DOS mode.”