One. Five. Zero. One hundred and fifty. 150 issues! What an awesome milestone for this project, and fitting as the last issue in 2019 (this was accidental, I swear!)

My gratitude to none other than Jesse Squires first and foremost, for starting this project and keeping it going up until issue 100. Thank you to Kristaps Grinbergs for helping out behind the scenes over the last months, as well as writing a few issues. Thanks to all other authors and those people helping behind the scenes for everything. You are the ones making this newsletter possible!

Lastly, thank you all dearly for reading and sharing the newsletter! When I took over this project from Jesse, I did so for two main reasons: I wanted to keep up to date with what’s going on with Swift, and have the possibility to share that with all others interested as well. And I feel that has worked out quite splendidly! Looking forward to continuing the journey in the next year.

And with that said, before we jump into the news from over the last two weeks, I want to wish you all a great end of 2019.

Interested in sponsoring Swift Weekly Brief? Learn more here.

Starter tasks

  • SR-11900 [Compiler] swift help doesn’t work
  • SR-11905 [Compiler] Objective-C interop allows creation of undefined behavior
  • SR-11918 [Compiler] Reject the combination of -enable-testing and -enable-library-evolution

News and community

Tanner Nelson announced Vapor 4, the fourth major release of the web framework for Swift! 🥳

Paul Hudson announced Swift for Good, a book covering 20 Swift topics written by 20 writers, with all revenue going to charity!

Bruno Rocha wrote a blog post on how OptionSet works inside the Swift compiler.

Commits and pull requests

Ankit Aggarwal merged a pull request that allows building and using the swiftpm binary that was built using swiftpm.

Rintaro Ishizaki opened a pull request that would allow for faster code completion by re-using the compiler instance in SourceKit. Neat!

Erik Eckstein merged a pull request that allows a first pass at cross-module optimization, allowing generic specialization across packages without manual @inlinable annotations.

Accepted proposals

SE-0268: Refine didSet Semantics was accepted.

The proposal has been accepted as it was originally proposed, prior to the second review.

The change overall received considerable support, despite being semantic-breaking in rare cases. Being able to make mutations in-place is an important performance win and one that many current users might already be expecting.

The second review proposed a small alteration to the original proposal: to warn on implicit use of didSet, because in the original review some reviewers felt that accessing the implicit parameter in the body of the function resulting in the fetching behavior could be harmful, so proposed a deprecation warning to be silenced by adding the argument explicitly. During the second review, it became clear that the feeling of most commenters was that the increased verbosity (and new warnings) did not justify the change. The core team agrees with the feedback, and so has accepted the original proposal.

Proposals in review

SE-0270: Add Collection Operations on Noncontiguous Elements is under review.

The proposal was returned for revision in order to investigate splitting it into smaller pieces. Nate Cook, the proposal author, has chosen to make several revisions, the most significant of which is to remove several sets of methods; you can see the raw difference here. The Core Team has elected to run a review of the proposal as revised rather than sending it back into the pitch phase.

It sometimes happens with re-reviews that the Core Team has substantively approved parts of the proposal and is asking the community to provide feedback on specific revisions. That is not the case here because the Core Team did not feel like it received a strong signal on the core proposal. Accordingly, please consider this to be a de novo review and provide feedback on the full proposal.

SE-0272: Package Manager Binary Dependencies is under review.

SwiftPM currently supports source-only packages for several languages, and with a very proscriptive build model which considerably limits exactly how the compilation of the source can be performed. While this makes packages consistent and to some extent “simple”, it limits their use in several important cases:

  • Software vendors who wish to provide easy integration with the package manager, but do not deliver source code, cannot integrate.
  • Existing code bases which would like to integrate “simply” with SwiftPM, but require more complicated build processes, have no recourse.

For example, consider these use cases:

  • Someone wants to create a Swift package for generating LLVM code. However, LLVM’s build process is far more complex than can be currently fit into SwiftPM’s build model. This makes building an easy to use package difficult.
  • A third-party wants to provide a Swift SDK for easily integrating their service with server-side Swift applications. The SDK itself relies on substantial amounts of internal infrastructure the company does not want to make available as open source.
  • A large company has an internal team which wants to deliver a Swift package for use in their iOS applications, but for for business reasons cannot publish the source code.

This proposal defines a new SwiftPM feature to allow SwiftPM to accept some forms of “binary packages”. This proposal is intentionally written to address the above use cases explicitly, it does not define a general purpose “binary artifact” mechanism intended to address other use cases (such as accelerating build performance).

SE-0273: Package Manager Conditional Target Dependencies is under review.

This proposal introduces the ability for Swift package authors to conditionalize target dependencies on platform and configuration with a similar syntax to the one introduced in SE-0238 for build settings. This gives developers more flexibility to describe complex target dependencies to support multiple platforms or different configuration environments.

This proposal resolves two use cases that the current version of the Package Manager doesn’t support very well. In the first scenario, packages that span multiple platforms may need to depend on different libraries depending on the platform, as can be the case for low-level, platform-specific code. In a second scenario, packages may want to link against libraries only in certain configurations, for example when importing debug libraries, which do not make sense to build and link in release builds, or when importing instrumentation logic, which only make sense in release builds when the developer can not benefit from debugging.

This proposal attempts to bring solutions to those use cases by allowing package authors to define under what build environments dependencies need to be built and linked against targets.

Swift Forums

Joe Groff shared some insights on generic type metadata prespecialization.

One source of memory and performance overhead in Swift code is the instantiation and fetching of type metadata. Even though generic specialization eliminates the need for type metadata in most fully-specialized code, we still need the metadata in many frequently-occurring situations:

  • Objects always need their class metadata, which serves as the “isa” pointer with the object’s method table and other dynamic metadata.
  • When putting a value inside an existential box, the type metadata for the value’s type is stored in the box to represent its dynamic type.
  • When calling into unspecialized code, type metadata for the generic type arguments has to be formed. Code may remain unspecialized because it crosses ABI boundaries or is invoked via dynamic reflection.

Tom Doron shared the Swift Server Work Group December 12th meeting notes.

Ian Partridge and Chris Bailey let the group know that following a review by IBM of its open source priorities, it has been decided that they will not be continuing to work on Swift in 2020. As a result, they are both standing down from the workgroup.

Ian Partridge will work to hand over responsibilities for the Swift Docker images and suggested a potential new owner from the community.

Ben Cohen pitched a proposal to make Swift’s modify accessors a public feature.

We propose the introduction of a new keyword, modify, for implementing mutable computed properties and subscripts, alongside the current get and set.

The bodies of modify implementations will be coroutines, and they will introduce a new contextual keyword, yield, that will be used to yield a value to be modified back to the caller. Control will resume after the yield when the caller returns.

This modify feature is currently available (but not supported) from Swift 5.0 as _modify, for experimentation purposes when reviewing this proposal.

Matthew Johnson pitched a proposal to introduce anonymous structs.

This proposal introduces anonymous structs using closure-inspired syntactic sugar as an alternative to a more verbose local struct declaration. As with closures, trailing syntax is supported.

While Swift has often been called a protocol-oriented language it still lacks some features necessary to facilitate protocol-oriented library designs in practice. One missing feature is syntactic support for ad-hoc, single-use conformances on par with the expressivity that closures provide for ad-hoc, single-use functions.

Local type declarations involve a lot of syntactic ceremony that is unnecessary for singe-use types. This ceremony includes a name, explicit protocol conformance declarations, and fully written declarations for all members. In addition to the ceremony of the local type declaration itself, use of the type requires explicit instantiation, which may itself be verbose if there are several stored properties to initialize.

Finally

A “funny” Swift thing.