Podcast episodes to listen to, interesting proposals and tools that help you go through all Swift packages. And more.

Interested in sponsoring Swift Weekly Brief? Learn more here.

Starter tasks

  • SR-11198 [Compiler] Compiler crash on inout-to-pointer used with @autoclosure param returning optional
  • SR-11261 [Compiler] Parser recovery for keyword after case declaration

Podcasts

In the latest Swift Community Podcast, Kateryna, Paul, Erica, and John talk about their first impressions on SwiftUI.

In the latest Swift Unwrapped episode, Jesse and JP discuss Generic Math Functions and Approximate Equality.

News and community

Dave Verwer announced The SwiftPM Library, a Swift Package Manager search engine.

In lights of the Combine release, Jasdev Singh wrote a post explaining reactive and imperative programming.

Commits and pull requests

Doug Gregor merged a pull request that “fixes a glaring algorithmic problem in code [he] wrote checks notes six years ago”. 😅

Slava Pestov merged a pull request that gets them closer to having local variables with lazy and property wrappers.

Andrew Trick merged a pull request where exclusivity enforcement is not just about safety - it also enables better optimizations.

Accepted proposals

SE-0261: Identifiable Protocol was accepted.

The proposal was positively received as addressing a common need for which a standard protocol is appropriate.

During review, there were some concerns about the use of the property id, with some preferring identifier to avoid clashes with existing properties, while others stated they would have the same problem with id. The core team feels that id, as the term of art, is the better choice. Future language features should provide a path to resolve clashes.

Proposals in review

SE-0263: Add a String Initializer with Access to Uninitialized Storage is under review.

This proposal suggests a new initializer for String that provides access to a String’s uninitialized storage buffer.

String today is well-suited to interoperability with raw memory buffers when a contiguous buffer is already available, such as when dealing with malloced C strings. However, there are quite a few situations where no such buffer is available, requiring a temporary one to be allocated and copied into. One example is bridging NSString to String, which currently uses standard library internals to get good performance when using CFStringGetBytes. Another, also from the standard library, is Int and Float, which currently create temporary stack buffers and do extra copying. We expect libraries like SwiftNIO will also find this useful for dealing with streaming data.

Swift Forums

Dean Harel pitched a proposal for a dedicated function for evaluating Void returning closures when an Optional instance is not nil.

A transformation of the shape, one that returns nothing, is not uncommon in our day-to-day tasks, and in my opinion deserves a name which clearly and conspicuously translates the writer’s intent in call-site.

In this respect, another Container type in Swift that has been added a dedicated method to handle such “transformations” is the Array type. Consider the following functions:

func map<T>(_ transform: (Element) throws -> T) rethrows -> [T]
func forEach(_ body: (Element) throws -> Void) rethrows

While we would all agree that forEach(_:) is not a necessity, we can also agree that for the task of printing all elements in an array, this:

[4, 2].forEach { print($0) }

reads much nicer than this:

_ = [4, 2].map { print($0) }

Thus I propose adding a parallel function to Array’s forEach(_:), taking advantage of a similar naming for convenience:

public extension Optional {
    func forValue(_ body: (Wrapped) throws -> Void) rethrows {
        guard let value = self else { return }
        try body(value)
    }
}

Giuseppe Lanza pitched a proposal to support @unrequired in function signatures for optional closure parameters.

From a perspective of a framework writer it is important to provide clear and understandable documentation for the correct usage of their APIs. Swift allows us to write functions that are at some extent self documenting, and clearly define what the function will actually do.

Franz Busch pitched a proposal to add support for binary dependencies in the Swift Package Manager.

This draft introduces support for binary dependencies in SwiftPM. It will allow vendors to upload artifacts for all supported platforms which will be resolved, downloaded and linked by SwiftPM. There are still some open things left, which can be found at the bottom, but we wanted to get community feedback before we continue with this.

Finally

You can do everything you set your mind to.