This year’s WWDC was a blast. Despite what is currently happening in the world I think Apple created a small “development holiday” for all of us. I think a new online conference reached far more folks around the world than ever before. We got completely revamped developer forums, as well as many community-organized side events that were not tied to any physical location, which is great.

This year we got great new things, especially in SwiftUI, that are driven by new cool additions to the Swift language. And much more. Now we have a full summer to explore new stuff and get ready for new Apple releases and slowly for Apple’s own built silicon.

Podcasts

In the latest episode of Swift Unwrapped, Jesse and JP talk about tuples.

In episode 75 of the Swift by Sundell podcast, Dave Verwer and Sven A. Schmidt join John to talk about their newly launched Swift Package Index, and what the overall state of Swift’s package ecosystem is. Also dependency management, composing libraries, deploying server-side Swift in production, and much more are discussed.

News and community

In this year’s WWDC 2020 Apple had two main sections of videos about the Swift language and relevant topics:

In addition to that, Tom Doron presented how to use Swift on AWS Lambda with Xcode.

Amy Tsai shared awesome sketch session notes for the Whats New In Swift session.

A great project by Federico Zanatello: WWDC Notes

  • The TL;DW for Apple’s WWDC videos. You can read session notes written by the community.

Apple released Xcode 12 and here are the release notes of what has changed in Swift.

Cory Benfield shared that the Swift Crypto 1.1.0 RC1 is available. It brings the new CryptoKit APIs from Apple’s WWDC20 platforms to all other Swift platforms.

The first release candidate of Swift for TensorFlow v.0.10.0 is out.

Bruno Rocha wrote a blog post about the benefits of using throwing functions.

Moritz Lang created a repository listing all things SwiftNIO.

Ole Begemann wrote a blog post explaining as, as?, and as!.

Commits and pull requests

Slava Pestov merged a pull request that fixes a bug in generic signature minimization. It turned out that the fix didn’t require a big redesign of the GenericSignatureBuilder after all. It’s just a five line addition of a new 'if' statement.

Michael Gottesman merged a pull request that adds an option that causes the generic specializer to validate newly specialized functions earlier when there is more information that can be put into a pretty stack trace.

Stephen Celis merged a pull request that improves performance of Collection.removeFirst(_:) where Self == SubSequence. You can read more about it here.

Luciano Almeida merged a pull request that resolves SR-5688: Unhelpful diagnostic when missing a ? in a KeyPath expression.

Mishal Shah merged a pull request to update master branch for Xcode 12 beta.

Accepted proposals

SE-0282: Interoperability with the C Atomic Operations Library was accepted.

This proposal does not specify whether/how dependency chains arising from the C/C++ memory_order_consume memory ordering work in Swift. The consume ordering as specified in the C/C++ standards is not implemented in any C/C++ compiler, and we join the current version of the C++ standard in encouraging Swift programmers not to use it. We expect to tackle the problem of efficient traversal of concurrent data structures in future proposals. Meanwhile, Swift programmers can start building useful concurrency constructs using relaxed, acquire/release, and sequentially consistent memory orderings imported from C.

Swift Forums

Erica Sadun pitched a proposal to migrate higher order function names to comply with API guidelines.

Swift’s higher order functions mostly predate the API guidelines and are based on terms of art. The community debated about this in the past and the “Term of Art” hammer won at that time. Perhaps we can reconsider now that Swift is entering its comfortable middle age reflective period as a missed opportunity.

It would be simple to alias map, filter, etc with API compliant names (apped, mapping, filtered, filtering), slow-walk-deprecate the former with the gentlest touch, and move towards a more consistent dev-facing vocabulary by replacing the terms in the SPL docs and devdoc tutorials (with footnotes or sidebars) to establish a new standard long before removing the old.

Breaking changes have a high bar so it would take such a slow and cautious approach to migrate the community towards these changes. Backwards compatibility would need to be maintained for a longer period of time than usual. I’m curious as to what people think.

Erica Sadun pitched a proposal to extend SwiftPM PackageDescription to introduce metadata.

A Swift Package defines the sources and dependencies for successful compilation. The PackageDescription specifies items like the supported Swift version, linker settings, and so forth.

What it does not do is offer metadata. You won’t find email for the active project manager, a list of major authors, descriptive tags, an abstract or discussion of the package, a link to documentation, deprecation information or links to superceding packages upon deprecation.

Doug Gregor starthed a conversation about revisiting the source compatibility impact of SE-0274: Concise magic file names.

In light of the discussion of principles for (trailing closure) evolution proposals and based on feedback we’ve received from the Swift 5.3 development snapshots, I’d like to revisit SE-0274: Concise magic file names. In particular, I feel like SE-0247 has violated the “Source Compatibility” principle more than is necessary, and that we should consider revising the proposal.

SE-0247 includes an additive change (#filePath literal to provide the full path to the file), but then introduces three changes that affect existing sources:

  1. #file literals have a different form that does not include the full path name. Therefore, the spelling #file has changed meaning.
  2. The compiler provides a warning when a wrapper around a #filePath-defaulting function passes it #file instead, or vice versa.
  3. Standard library functions like precondition currently use #file, and therefore have had their behavior changed to no longer produce the full path name by default.

Tom Doron shared meeting notes for the Swift on the Server Workgroup June 10th, 2020 meeting.

Frederick Kellison-Linn shared a proposal that introduces a syntax for defining function-typed variables which have compound names.

This proposal introduces a syntax for defining funciton-typed variables which have compound names (i.e., names with argument labels). This allows the call sites of such variables to achieve the same clarity that is achieveable with func declarations.

Shai Mishali pitched a proposal to introduce AnonymousKeyPath.

In many challenges of API Designs, you want your consumer to provide a way to get/set a specific concrete type.

Today, a consumer can express this idea by a Key Path, a wonderful concept in Swift. My consumer can tell me:

  • This is how you can get a String from MyObject (KeyPath)
  • This is how you can mutate a String on MyObject (WritableKeyPath)

Commonly, though, you want to ask a consumer a different set of questions:

  • Give me a way to retrieve a String on an arbitrary object
  • Give me a way to mutate a String on an arbitrary object

While not caring what is the Root of that String, as long as you fulfil the concrete requirement.

Unfortunately, as of today there’s no way to express a Key Path which isn’t bound to a specific concrete Root.

Mattt gave an update on a pitch for a Swift package registry service.

A primary goal of the proposed registry service is to provide strong guarantees that the package you downloaded is authentic. One approach is built on trust: If you assume that a registry always sends you exactly what you ask for, you only need to verify the sender (though it wouldn’t hurt to verify the contents anyway).

Modern information security relies on public-key cryptography to verify claims of identity. Broadly speaking, there are two approaches to certificate trust:

The original proposal relies on both TLS and PGP for security; TLS to verify the identity of the registry’s domain (e.g. github.com) and PGP to verify the registry as the creator of the package archive. My thinking was that this “belt and suspenders” approach would offer more security than relying on one alone. Instead, this turned out to be more of a “weak link in the chain”.

Finally

Finally, we have Nyan Cat in Swift. 🏳️‍🌈

Acronyms, acronyms everywhere…