The last two weeks started quite slow, but now it seems that things are starting to heat up. Apple has released more information about WWDC 2020, announcing it will take off on June 22.

Also, Google Summer of Code 2020 students have been announced. They will be working on important and exciting projects for Swift over the summer, being mentored by the people at Apple!

Interested in sponsoring Swift Weekly Brief? Learn more here.

Podcasts

In episode 71 of the Swift by Sundell podcast, Dave Abrahams joins John Sundell to talk about Protocol-Oriented Programming and how to make the most out of the Swift Standard Library. Also, discussions on Swift’s overall design, why it puts such a strong emphasis on value types and protocols, and how it’s been influenced by other languages.

News and community

An announcement has been made about even more Linux platforms officially supporting Swift.

Development is open for Swift 5.2.4 for Linux, with a planned release at the end of May 2020.

Kenta Kubo tweeted how to use a SwiftPM package on Swift Playgrounds on iPad by using Working Copy and Textastic.

Dario Rexin announced Swift 5.2.3 for Linux.

Paul Hudson shared tweeted some of the features coming in Swift 5.3.

Commits and pull requests

Slava Pestov merged a pull request that ripped out the old dependency graph implementation.

Ted Kremenek merged a pull request that fixes _modify for wrapped properties with observers. It got some community members very excited. :)

Johannes Weiss created a pull request that allows completely single-threaded NIO programs.

Doug Gregor merged a pull request that extends function builders with support for for..in loops.

Slava Pestov opened a pull request that removes the integrated REPL. Read more on the forum discussion.

The integrated REPL has been deprecated in favor of the LLDB REPL for a while, and the implementation had accumulated some amount of technical debt throughout the code base. Since most people don’t use it and are not even aware that it exists, we can remove it.

Accepted proposals

SE-0279: Multiple Trailing Closures was accepted in its second review.

The amended proposal was received more positively. Several reviewers who had opposed the original proposal were now unreservedly in favor. Others supported the new proposal overall but expressed a preference for also allowing an argument label on the first closure.

However, many reviewers continued to oppose the amended proposal. Some reviewers expressed their dislike of trailing closures overall, or disputed the need to allow multiple trailing closures. The core team continues to believe, as we stated at the start of the second review, that the underlying motivation for the proposal is sound and changes here are merited. Other reviewers disliked the specifics of the change or felt that it was not tenable without allowing an argument label on the first closure or without substantial changes to the model for type-checking calls with trailing closures.

Returned proposals

SE-0282 has been returned for revision.

During the review, support was nearly unanimous for the memory model the proposal establishes, bringing Swift in line with the model standardized by C. The core team concurs with the review discussion on this subject, and would like to see a revised proposal that focuses on specifying the memory model. Guaranteeing a C-compatible memory model allows developers that currently wrap atomic primitives written in C and import them into Swift to rely on this continuing to work. This would also provide stable ground for building atomics packages outside of the standard library for experimentation and use by early adopters. The Swift project itself plans to develop one of these packages

Proposals in review

SE-0283: Tuples Conform to Equatable, Comparable, and Hashable is under review.

Introduce Equatable, Comparable, and Hashable conformance for all tuples whose elements are themselves Equatable, Comparable, and Hashable.

Tuples in Swift currently lack the ability to conform to protocols. This has led many users to stop using tuples altogether in favor of structures that they can them conform protocols to. The shift from tuples to structures have made tuples almost feel like a second class type in the language because of them not being able to do simple operations that should just work.

Swift Forums

Miguel de Icaza pitched a proposal on Swift package installation.

It would be desirable to simplify the use of executables that have been compiled with swift build and installing the binary, payloads and other requirements into either a global location usable by all users on the system, or make it available only to the current user.

This would simplify the distribution and usage of Swift-authored tools, as instructions for installing the software would be as simple as directing the user to type swift tool install.

Jon Shier started a discussion about newtype.

newtype has come up again and since I don’t have a specific pitch I thought I’d start some discussion outside of the older thread. Before diving into specific syntax or implementation details I think it would be good to gather ideas about what people want out of such a feature and what they feel is most important.

Cory Benfield pitched a proposal to enable non-resilient Swift libraries to provide “extensible” enums.

This proposal adds an attribute to allow Swift enumerations to opt-in to an extensible behaviour. This reconciles a feature mismatch between resilient and non-resilient dialects of Swift, and makes Swift enumerations vastly more useful in the public API of non-resilient Swift libraries.

Adrian Meister ask about what kind of breaking changes are considered/allowed in Swift 6.

There could also be an opportunity for us to eliminate the language dialect here in Swift 6, and make it so that the next breaking change of the language always defaults enums to non-frozen behavior in all modules.

I read these kind of things very frequent in the last couple weeks. That makes me wonder, what kind of breaking changes are considered/allowed in Swift 6? There are a couple other things that come to my mind that would require a breaking change to be really fixed / work.

David Goldman pitched a proposal to add some indication of file status to SourceKit-LSP.

  1. Give the user an idea of what they should expect - is the build system initializing? Does the build system recognize the file? Is (pre)building still required before full functionality can occur?
    • This will increased perceived reliability as long as these statuses are accurate and clear
    • SourceKit-LSP can also change behavior based on these states, e.g. potentially hold back diagnostics if the build system still needs to prebuild.
  2. Make the clangd/sourcekitd loading state clear. This helps isolate build system vs. compiler issues and lets the user know the compiler is working (even if we can’t provide progress estimates)

Kaitlin Mahar pitched a proposal to create a MongoDB Swift driver.

mongo-swift-driver is a client library for using MongoDB from Swift. Its module MongoSwift provides a SwiftNIO-based asynchronous API for interacting with the database. The core type, MongoClient, maintains a pool of connections to servers in a MongoDB deployment and provides an interface for querying, inserting, and updating data in the deployment. In addition, the client handles authentication, TLS, topology monitoring, and automatically retrying failed commands. The driver also contains a BSON implementation allowing users to create and manipulate MongoDB documents and to convert between documents and native Swift types.

Owen Voorhees pitched a proposal making Never a true bottom type in Swift.

SE-0102 introduced the Never type, an enum with no cases, as a way of conveying to both the compiler and user that a function cannot return by normal means. Instead, a Never-returning function might throw an error, trap, or simply never terminate. Over time, the type’s uses have expanded to model other “impossible” situations. For example, thanks to SE-0215, which conformed Never to Error, one can construct a Result<String, Never> which is guaranteed to represent a success state

Nate Cook pitched a proposal that modifies the behavior of the Sequence.max algorithms to match the free max(...) functions in cases where there is more than one “maximum” element.

SR-12113 asks that we codify the behavior of the min and max methods on sequences into a guarantee in the documentation. Unfortunately, the current behavior of the max methods is inconsistent with other places in the standard library that identify the maximum of two or more inputs, when there is more than one “maximum” value.

Specifically, the sequence method returns the first of several maximum elements in the sequence, while the other APIs (the max free functions and the FloatingPoint.maximum static methods) return the last of the maximum values. In general, this difference behavior isn’t noticeable, but for class instances it’s observable through instance identity, and when using the predicate-based method can be observed through whatever properties aren’t included.

tcldr pitched a proposal about a tiny refinement to the Standard Library to provide a convenience member on Result when Success is Void.

Result types with a success type of Void are commonly used when no further information about the result of the operation are required – other than to know it was successful. In these cases, it is necessary to return a Result via Result.success(()).

Finally