WWDC is now very, very near. Only a little bit more than a weekend before things kick off. Very exciting!

Also — a note regarding this issue’s sponsor. This was so unexpected — but so, so very kind. His point is spot on. Putting together Swift Weekly Brief time and time again is something I’m very happy to do, and it is a real pleasure to be able to support the Swift community this way.

But it isn’t always glamorous, so don’t take things for granted.

Thank you, Paul! ❤️

Enjoy WWDC everyone, and looking forward to a hopefully jam-packed issue in two weeks!

News and community

Dave Verwer and Sven A. Schmidt announced the Swift Package Index, “the place to find Swift packages”.

Paul Hudson put together a repository with an overview of everything that is being organized around WWDC in our community.

Kaitlin Mahar announced the release of the MongoDB Swift driver v1.0! 🥳

Commits and pull requests

Slava Pestov wrote a thread about Robert Widmann’s work on improving incremental builds.

Proposals in review

SSWG-0013: Swift AWS Lambda Runtime is under review.

Many modern systems have client components like iOS, macOS or watchOS applications as well as server components that those clients interact with. Serverless functions are often the easiest and most efficient way for client application developers to extend their applications into the cloud.

Serverless functions are increasingly becoming a popular choice for running event-driven or otherwise ad-hoc compute tasks in the cloud. They power mission critical microservices and data intensive workloads. In many cases, serverless functions allow developers to more easily scale and control compute costs given their on-demand nature.

When using serverless functions, attention must be given to resource utilization as it directly impacts the costs of the system. This is where Swift shines! With its low memory footprint, deterministic performance, and quick start time, Swift is a fantastic match for the serverless functions architecture.

Combine this with Swift’s developer friendliness, expressiveness, and emphasis on safety, and we have a solution that is great for developers at all skill levels, scalable, and cost effective.

SSWG-0014: Swift Backtrace is under review.

Printing backtraces when applications crash is a critical component in diagnostics of real-world production issues on the Server.

When applications crash on the Server, it is desired for the crash information to be captured and printed along side the application logs so that log aggregation tools (e.g. Splunk) could include the crash information and used for alerting and further analysis offline.

At this point of time, Swift does not print crash backtraces when compiled in release mode on Linux. This means that Swift server applications can crash silently making the operation of such applications difficult.

Swift Forums

Guy Brooker pitched a proposal for static thread safety.

One of the principal goals of Swift is “to make writing and maintaining correct programs easier for the developer”. Swift has gone a long way to eliminate many common errors found in other programming languages through static type checking, ensuring safe memory access. The free for all in C where anything and everything was possible by casting pointers to different data types is thankfully over.

Most modern non-trivial Swift applications require some form of concurrency, asynchronously retrieving information over a network, firing timers , updating UI or handling notifications, however Swift does not provide concurrency primitives today. Accessing variables concurrently in Swift is inherently dangerous, and is a very easy mistake to make. The Swift language provides no safety for a developer of concurrent code, leaving them in a similar position as the C programmer of yesteryear, permitting frequent programming errors to go un-flagged.

This proposal sets out some small language changes which would allow the compiler to spot basic concurrent programming errors. To be clear, the title of this proposal “Static thread safety” is intended to mean compile time thread safety checks. It does not add concurrency primitives, nor provide any automatic concurrency or thread safety. It simply allows developers to write safer code.

Johannes Weiss shared some thoughts on running many operations concurrently, but in batches.

So here’s some more example code for a question that I’ve been asked repeatedly: How can I run a large number of operations whilst limiting this to N running at the same time. You may want to do that if you have to do many HTTP requests to a website but you don’t want to overload the website and say do only 10 at the same time.

Quincey Morris pitched another proposal for async / await.

As far as I’m concerned, the goal here is to add Swift language features to provide a path-of-execution serialization operator, along with a genuine notion of an asynchronous function.

Beyond that: there is a further discussion which we haven’t even started having yet. There are other asynchronous patterns we might like to provide for. How about, for example, an await operator that operates on “groups” of asynchronous functions (aka concurrency or dispatch groups)? How about an algebra of futures or promises that can be used within the implementations of asynchronous functions to provide more sophisticated usage patterns?

Dave Abrahams pitched a proposal for a way to check for unique storage in standard library collections.

Consider:

struct Vector<T> {
  var scalars: [T]
  static func +=(lhs: inout Vector, rhs: Vector) {
    for i in lhs.scalars.indices { lhs.scalars[i] += rhs.scalars[i] }
  }
}

This implementation is suboptimal in the case where lhs.scalars shares its storage with another array, because it first copies the scalars in lhs into new storage and then writes over them, accumulating elements from rhs into it. What we really want to be able to do is:

struct Vector<T> {
  var scalars: [T]
  static func +=(lhs: inout Vector, rhs: Vector) {
    if hasUniquelyReferencedStorage(&lhs.scalars) {
      for i in lhs.scalars.indices { lhs.scalars[i] += rhs.scalars[i] }
    }
    else { 
      lhs = lhs + rhs // build new storage once and replace old storage with it
    }
  }
}

Currently the only known way to do the check for unique storage is a horrible hack that probably violates the memory model.

Ideally, we would have a way to ask generically whether all the references in any given type were uniquely-referenced, but as a start, it would be extremely useful just to be able to ask that question about arrays, sets, and dictionaries. My pitch to you is that we expose unsafeHasUniquelyReferencedStorage in the standard library.

Finally

Remember Mac OS X? Those were the days. 🦁