We have a fantastic new domain: swiftweeklybrief.com. 🎉

I would like to personally thank Jeroen Leenarts for his tremendous help with the new email marketing platform.

This month is also an opportunity to celebrate the amazing women in our community. Holly Borla, a lead member of the Diversity in Swift work group, highlights many prominent contributers on the Swift.org blog. If you’d like to get involved, please message @diversity-work-group on the Swift Forums.

We’re glad to say that the Actors proposal is now under review. Some vast improvements are coming to Swift later this year!

There are so many great pitches for this year’s Google Summer of Code for the Swift language. Some of these pitches will be implemented by university students over the summer.

Thank you, everyone, for reading and supporting this project!

News and community

Nicole Jacque shared the release process and estimated schedule for Swift 5.5.

Holly Borla and Paul Hudson wrote a blog post celebrating Women’s History Month.

Great Twitter thread about how to initialize an array and what effects this has during compile time.

Commits and pull requests

Steven Wu merged a pull request that emits diagnostics and errors out when swift-api-extract fails to load a module. This PR resolves SR-14311.

Holly Borla merged a pull request that reworks the dependencies between property wrapper requests.

Accepted proposals

SE-0302: Sendable and @Sendable closures was accepted with modifications.

Feedback in the second round of review was generally positive. There was a fair amount of discussion about the new names, and people seemed to generally approve of the name Sendable for the protocol. Consensus was weaker about the name @sendable for the function-type attribute; the Core Team discussed this and decided to steal an idea from Matthew Johnson and rename the attribute to @Sendable. This name better emphasizes the core idea of the attribute (that so-modified function values have to conform to Sendable, and thus their captures must, too), and it also aligns with an interesting future direction (to allow similar protocol-based constraints on specific function types). The review was briefly extended, and feedback on that rename was strongly positive.

SE-0226: Package Manager Target Based Dependency Resolution amendment was accepted.

SE-0295: Codable Synthesis for enums with Associated Values was accepted.

There was general consensus that the solution would help a number of users, even if the encoding was not unanimously agreed upon. The core team does not believe that Codable represents the complete solution for the needs of serialization. There is a new thread which discusses the various requirements of the serialization solution in Swift.

Returned proposals

SE-0303 has been returned for revision.

The feedback to idea of extending SwiftPM with plugins, the concrete design of the plugin system, and the tradeoffs the design make was very positive. Both authors and users of potential future plugins have provided input that the proposed design would work in real-world use cases, and that today require solutions outside of SwiftPM. However, there were a number of ideas that came up during the review that the core team feels would be good to adopt.

Proposals in review

SE-0305: Package Manager Binary Target Improvements is under review.

This proposal extends SwiftPM binary targets to also support other kinds of prebuilt artifacts, such as command line tools. It does not in and of itself add support for non-Darwin binary libraries, although the proposed improvements could be a step towards such support.

SE-0306: Actors is under review.

This review is part of the large concurrency feature, which we are reviewing in several parts. While we’ve tried to make it independent of other concurrency proposals that have not yet been reviewed, it may have some dependencies that we’ve failed to eliminate. Please do your best to review it on its own merits, while still understanding its relationship to the larger feature. You may also want to raise interactions with previous already-accepted proposals – that might lead to opening up a separate thread of further discussion to keep the review focused.

SE-0307: Allow interchangeable use of CGFloat and Double types is under a review.

I propose to extend the language and allow Double and CGFloat types to be used interchangeably by means of transparently converting one type into the other as a sort of retroactive typealias between these two types. This is a narrowly defined implicit conversion intended to be part of the existing family of implicit conversions (including NSType <=> CFType conversions) supported by Swift to strengthen Objective-C and Swift interoperability. The only difference between the proposed conversion and existing ones is related to the fact that interchangeability implies both narrowing conversion (Double -> CGFloat) and widening one (CGFloat -> Double) on 32-bit platforms. This proposal is not about generalizing support for implicit conversions to the language.

Swift-evolution thread: Discussion thread topic for that proposal

SE-0293: Extend Property Wrappers to Function and Closure Parametersors is under a third review.

Property Wrappers were introduced in Swift 5.1, and have since become a popular mechanism for abstracting away common accessor patterns for properties. Currently, applying a property wrapper is solely permitted on local variables and type properties. However, with increasing adoption, demand for extending where property wrappers can be applied has emerged. This proposal aims to extend property wrappers to function and closure parameters.

Swift Forums

Doug Gregor shared a draft proposal for global actors 139.

Global actors use the same actor-isolation model from the main proposal, but allow us to state that various functions and types scattered throughout the program will nonetheless need to be synchronized through one, global, actor. This is particularly important for allowing us to model the main thread as an actor.

Johannes Weiss pitched a proposal to introduce #module to get the current module name.

Currently Swift has a number “magic identifiers”: #fileID, #file, #filePath, #file, #function, #line, #column, and #dsohandle which are extremely useful, for example for debugging and logging.

In log output, it’s a common practise to output the filename (and sometimes the line number) where the log message was emitted from. In most cases however, only the basename of a file is logged, ie. if a log messages originates from /Users/me/MyProject/Sources/MyModule/MySubfolder/BestFile.swift, then commonly only the “basename” BestFile.swift is logged because the full paths can become very long.

Christian Carter started a discussion about swift-corelibs-foundation on Mac OS.

Finally

Happy St. Patrick’s Day ☘️