Have you noticed how the last two weeks have been pretty low-key for the Swift community? I feel this is a lull before the storm of September comes and we all know what that means. Folks are holding their breath, eager to find out news from Apple.

Personally, this time is quite challenging for me as I am getting ready to take the stage at 360iDev conference. Unfortunately, the US hasn’t opened their borders yet, even for fully vaccinated people, so I’m participating online this time. But despite not being able to meet old friends and make new friends in person, I’m truly looking forward to connecting with people and sharing my experience using Swift for rapid development. Let me know if you’re participating in 360iDev and let’s meet up!

For those of you who want to give back to community and support the Swift Weekly Brief, we are open for sponsors.

Interested in sponsoring Swift Weekly Brief? Learn more here.

Starter tasks

SR-15026 [Compiler] Fix-it for deprecated initializers removes the .init part from self.init

News and community

Collin Donnell tweeted that Swift is the only language they could find with over 100 keywords.

Khawer Khaliq wrote a blog post explaining the power of optional chaining in Swift.

Antoine van der Lee has created a great resource about Swift keywords.

Ayman Fayez wrote a post about copy-on-assignment vs. copy-on-write in Swift.

Excellent writeup covering all of Swift’s internal underscored attributes by Varun Gandhi.

Proposals in review

SSE-0320: Coding of non String / Int keyed Dictionary into a KeyedContainer is under review.

The current conformance of Swift’s Dictionary to the Codable protocols has a somewhat-surprising limitation in that dictionaries whose key type is not String or Int (values directly representable in CodingKey types) encode not as KeyedContainers but as UnkeyedContainers. This behavior has caused much confusion for users and I would like to offer a way to improve the situation.

Swift-evolution thread: [Pitch] Allow coding of non-String/Int keyed Dictionary into a KeyedContainer

Swift Forums

Cal Stephens pitched a proposal introducing a guard capture specifier for closure capture lists.

In some classes of Swift programming, such as UI programming, closures are a predominant way to perform action handling and send event notifications between multiple objects. When passing closures between parent objects and their children, special care must be taken to avoid retain cycles.

weak captures are often the preferred method to avoid retain cycles. In action handling and event notification closures, there is typically no work to perform if self (or other captured objects) no longer exist. Because of this, a large number of these closures simply guard that the weakly captured object still exists, and otherwise do nothing.

Johannes Auer started [a thread] about AnyAsyncSequence in Swift.

Swift on the Server Workgroup meeting notes:

Benjamin Driscoll pitched an idea to add structural opaque result types.

An opaque result type may be used as the result type of a function, the type of a variable, or the result type of a subscript. In all cases, the opaque result type must be the entire type. This proposal recommends lifting that restriction and allowing opaque result types in “structural” positions.

We should allow opaque result types in structural positions in the result type of a function, the type of a variable, or the result type of a subscript.

mattt pitched a proposal that would add a publish endpoint to the package registry service.

A package registry is responsible for determining which package releases are made available to a consumer.

Currently, the availability of a package release is determined by an out-of-band process. For example, a registry may consult an index of public Swift packages and make releases available for each tag with a valid version number.

Having a standard endpoint for publishing a new release to a package registry would empower maintainers to distribute their software and promote interoperability across service providers.

Nicholas Maccharoli proposed a shordhand solution for optional unwrapping.

Vihan Bhargava wrote an aweseome overview of the new SortedDictionary and SortedSet APIs in swift-collections.

The Swift Collections package currently includes two data structures which maintain its members in a well-defined order: OrderedSet and OrderedDictionary. These types are useful in a variety of use-cases, as they enumerate their elements in insertion order. However, there also exist many situations where its desired to maintain elements in an order specified by a predefined comparator. For example, a common pattern in user interfaces is displaying a list with entries sorted in some order, such as in chronological order.

Quick ad hoc implementations of sorted data structures can have many pitfalls. A naive implementation can devolve to quadratic performance. A smarter implementation using binary search is difficult to get correct and has subtle potential pitfalls. For this reason, there is natural place to provide high-performance, production-grade sorted data structures.

Andrew Trick pitched an idea to add an implicit pointer conversion for C interoperability.

C has special rules for pointer aliasing, for example allowing char * to alias other pointer types, and allowing pointers to signed and unsigned types to alias. The usability of some C APIs relies on the ability to easily cast pointers within the boundaries of those rules. Swift generally disallows typed pointer conversion. See SE-0107 UnsafeRawPointer API. Teaching the Swift compiler to allow pointer conversion within the rules of C when invoking functions imported from C headers will dramatically improve interoperability with no negative impact on type safety.

Brennan Stehling proposed to add the throw coalescing operator to the Swift language.

I’d really like syntax for do/try/catch which is as compact as nil coalescing in Swift. And so I put together a working implementation which I’d like to refine further. So far I have !! defined as my operator much like ?? for nil coalescing so it is familiar. The left operand would the work while the right would handle the error.

Finally