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.
News and community
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.
Commits and pull requests
Proposals in 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.
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.
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.
[..] 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
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
_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
ManagedBufferinstance, even in the (hopefully) vast majority of cases where
ManagedBuffer.capacityis never called outside of the closure passed to the
I believe the stdlib’s APIs shouldn’t be needlessly difficult to implement on particular platforms.
ManagedBuffer’s implicit requirement for a working
This seems like as good an excuse as any to start discussing a revision of these APIs.
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.
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.
Sometimes debugging can be quite “fun”.