Issue #191 12 Aug 2021
Written by: Kristaps Grinbergs
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.
SR-15026 [Compiler] Fix-it for deprecated initializers removes the
News and community
Proposals in review
The current conformance of Swift’s
Codableprotocols has a somewhat-surprising limitation in that dictionaries whose key type is not
Int(values directly representable in
CodingKeytypes) 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-
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.
weakcaptures 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
guardthat 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:
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.
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.
The Swift Collections package currently includes two data structures which maintain its members in a well-defined order:
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.
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.
I’d really like syntax for
catchwhich is as compact as
nilcoalescing 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
nilcoalescing so it is familiar. The left operand would the work while the right would handle the error.