Issue #181 25 Mar 2021
Written by: Kristaps Grinbergs
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!
Thank you, everyone, for reading and supporting this project!
Be the best lead software developer you can be. Learn best practices for being a great lead software developer. In this book Jeroen will provide you with best practices and tools to be the best lead developer you can be. For yourself, your peers and the business leaders you are working with.
News and community
Great Twitter thread about how to initialize an array and what effects this has during compile time.
Commits and pull requests
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
Sendablefor the protocol. Consensus was weaker about the name
@sendablefor 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.
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
Codablerepresents the complete solution for the needs of serialization. There is a new thread which discusses the various requirements of the serialization solution in Swift.
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
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.
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.
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 (
CGFloat) and widening one (
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
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.
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.
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.swiftis logged because the full paths can become very long.
Happy St. Patrick’s Day ☘️