Summer is already in its second half and seems that the Swift community has gained some steam before the official Xcode releases.

Additionally, the people working on Swift on the server have great news about AWS Lambda and Kitura is now a community project!

I think this is a calm before the (autumn) storm. We will have more awesome news in the coming weeks.

Interested in sponsoring Swift Weekly Brief? Learn more here.

Podcasts

In the latest episode of Swift Unwrapped, Jesse and JP talk about package registries and indexes.

News and community

Dario Rexin shared that Swift 5.2.5 for Linux has been released and downloads are available on swift.org.

An interview with Chris Lattner on the Possibility of Machine Learning-Enabled Compilers.

Fabian Fett wrote a blog post explaining how to create your first HTTP endpoint with Swift on AWS Lambda.

Mattt shared that swift-doc 1.0.0-beta.4 is now available, with several visual and functional bug fixes.

The next release promises to be the biggest yet, with plans to support DocSet output, along with raw data formats like JSON, RDF, and SQLite. I’m excited to get that out to you all to try out in the next week or two.

Tibor Bödecs shared a blog post on Feather CMS. A modern Swift-based Content Management System powered by Vapor 4.

Ole Begemann tweeted about how to get up and running with Swift WebAssembly, from writing a simple program to running it in the browser.

Harshil Shah wrote a blog post explaining Swift’s collection types.

John Sundell wrote an article explaining Swift’s function builders.

Danny Sung announced Kitura is now a community project.

Commits and pull requests

Knock YOCKOW merged a pull request that fixes SR-10689: Fix bugs of DataProtocol’s firstRange(of:in:)/lastRange(of:in:).

Erik Eckstein merged a pull request that handles static let variables for String constant folding.

Andrew Trick merged a pull request that adds AccessedStorage::Tail access kind and removes more exclusivity checks.

Stephen Canon opened a pull request that adds checks that the endpoints of partial ranges are not-NaN.

Proposals in review

SSWG-0015: Swift Service Lifecycle is under review.

Most services have startup and shutdown workflow-logic which is often sensitive to failure and hard to get right. Startup sequences include actions like initializing thread pools, running data migrations, warming up caches, and other forms of state initialization before taking traffic or accepting events. Shutdown sequences include freeing up resources that hold on to file descriptors or other system resources that may leak if not cleared correctly.

Today, server applications and frameworks must find ways to address the need on their own, which could be error prone. To make things safer and easier, Service Lifecycle codifies this common need in a safe, reusable and framework-agnostic way. It is designed to be integrated with any server framework or directly in a server application’s main.

Swift Forums

Matthew Cheok pitched a proposal on stored properties in extensions.

A very common pattern for organizing methods is using extensions within the module a type is declared in, in order to group methods semantically or for some other reason. These methods behave as if they are declared within the initial declaration itself and UIKit also uses this system of organization in its (generated) Swift interfaces. However, we can’t do this today with properties because all stored properties need to be declared within the initial declaration.

Richard Clements pitched a proposal about deferred property wrappers.

I wanted to make a pitch for a deferred style of property wrapper, that will work with lazy properties only. The purpose is that you would be able to use another (non lazy) property as a dependency for the property wrapper.

Elvis Shi pitched a proposal to add sort(by:) , min(by:) and max(by:) with keyPaths.

[..] now we’ve got the new KeyPath feature, but we still don’t have a convenient method to sort a sequence, or get the max / min element by its elements’ properties

Todd Varland shared the Swift Server Work Group July 8th, 2020 meeting notes, and Peter Adams shared the July 29th, 2020 meeting notes.

Karoy Lorentey pitched a proposal on how to iron out the ManagedBuffer API wrinkles.

As uncovered in PR #31686, the API of ManagedBuffer (and it’s less-liked sibling ManagedBufferPointer) implicitly assume that it’s possible to easily retrieve the size of a dynamically allocated chunk of memory. Platforms often allow this through functions like malloc_size, malloc_usable_size or _msize — but it turns out not all of them do. In particular, OpenBSD evidently doesn’t support this.

This makes these stdlib APIs suboptimal — on OpenBSD, the implementation would need to bend over backwards store the allocated capacity within the class instance, even though it is practically always duplicated in Header. The extra storage would waste memory and complicate element access in every ManagedBuffer instance, even in the (hopefully) vast majority of cases where ManagedBuffer.capacity is never called outside of the closure passed to the create method.

I believe the stdlib’s APIs shouldn’t be needlessly difficult to implement on particular platforms. ManagedBuffer’s implicit requirement for a working malloc_size seems unreasonable.

This seems like as good an excuse as any to start discussing a revision of these APIs.

Michael Verges pitched a proposal that executable-only dependencies would allow packages to be imported only for use in the package’s development environment.

CLI tools distributed through Swift Packages, such as linters or documentation generators, are currently imported as dependencies. Although these dependencies may only exist to use as an executable during development, the dependencies are shipped with the package. End-users of a package do not need to inherit development tools from the package.

This can encourage package developers to use more developer tools without frustrating end-users with unused dependencies.

Tanner Nelson pitched a proposal to implement a Generic Connection Pool.

Connection pooling is a critical component for many server-side applications. I would attempt to summarize connection pooling here, but honestly Wikipedia’s page does a better job:

In software engineering, a connection pool is a cache of database connections maintained so that the connections can be reused when future requests to the database are required. Connection pools are used to enhance the performance of executing commands on a database.

Finally

Taylor Swift as classic programming textbooks.

Sometimes debugging can be quite “fun”.