Issue #184 06 May 2021
Written by: Kristaps Grinbergs
Let’s start with the most important news: Swift 5.4 has been released alongside Xcode 12.5. It has some notable new features and additions like result builders, multiple variadic parameters, and more.
WWDC is just one month away! Who knows, maybe this is the reason why so many Swift Evolution proposals are in review or have been accepted?
For the last couple of weeks I have been pretty swamped with work, and I’m glad that I’m not alone on this project. If you want to get involved, or your company wants to sponsor, it would be very much appreciated. Thank you, everyone!
Never lose a copy again with Paste. It’s like a time machine for your clipboard that stores every link, image, file, or piece of code you copy and lets you access it within seconds. Try Paste for free and start working faster, better, and smarter.
refactor-check-compilesshould generate both
dump-rewrittenfrom a single
News and community
Commits and pull requests
For this second review, we had asked the community to explore the question of whether let bindings should be exceptional in their default actor isolation behavior, and based on community feedback, the Core Team has accepted the proposal with the modification that let bindings should be isolated by default, consistent with what is proposed for other declarations. Several topics, in addition to isolation of lets, came up in the second review…
The second review of SE-0303 has concluded. Feedback in the first review was positive and feedback from the second review has been largely informational. The proposal is accepted with some minor clarifications (diff).
The second review of SE-0305 has concluded. Feedback in the first review was positive and feedback from the second review has been largely informational. The proposal is accepted with some minor clarifications (diff).
The Core Team considered a number of points that came up in the discussion:
- There was some discussion about the placement of effects specifiers (
throws), with a request to move the specifiers to the property declaration itself rather than being specified on the getter. The proposal author has clarified why the proposed syntax is the appropriate syntax. The proposal will be amended with this rationale.
- It was noted that further extension of effects to writable properties would make it hard for users to separate the getter and setter declarations
Beyond the enthusiastic positive response, there was additional interest in further enhancements in the same direction. The core team believes that additional refinement of conditional compilation is something that the language would benefit from. As such, proposals extending support towards conditional compilation of repeated lexical constructs, e.g. elements within an array literal, would be welcome. For non-repeated constructs, there are potential issues with the parsing, for example in the removal of a binary operator may change the operator precedence of subsequent expressions, and this would require careful, deliberate handling. Such a change is not unreasonable, but would demand an appropriate level of design and care towards an implementation.
There was a lot of enthusiasm for removing the infamous “protocol can only be used as a generic constraint because it has Self or associated type requirements” restriction, and the Core Team agrees that at this point in Swift’s development, it serves no technical purpose, and the problems it causes are worse than the ones it tries to avoid. The Core Team also acknowledges that this proposal by itself does not solve all the problems with existentials in Swift, but that it is important progress in unblocking further improvements to generics and existentials going forward.
Proposals in review
This proposal aims to fix the lack of
Collectionconformance of the sequences returned by
enumerated(), preventing them from being used in a context that requires a
Collection. Also included is the addition of the
Collectionas a more ergonomic, efficient, and correct alternative to
Swift-evolution thread: Pitch
The first review received a lot of very useful feedback. In response, the author has made major changes to the proposal. The Core Team has decided to put up the revised proposal for de novo review; that is, you should essentially review this proposal as if it were an entirely different proposal.
The Swift actors proposal introduces the notion of actor-isolated declarations, which are declarations that can safely access an actor’s isolated state. In that proposal, all instance methods, instance properties, and instance subscripts on an actor type are actor-isolated, and they can synchronously use those declarations on
self. This proposal generalizes the notion of actor isolation to allow better control, including the ability to have actor-isolated declarations that aren’t part of an actor type (e.g., they can be non-member functions) and have non-isolated declarations that are instance members of an actor type (e.g., because they are based on immutable, non-isolated actor state). This allows better abstraction of the use of actors, additional actor operations that are otherwise not expressible safely in the system, and enables some conformances to existing, synchronous protocols.
asyncfunctions can only directly be called from other
asyncfunctions. In synchronous code, the only mechanism provided by the Swift Concurrency model to create asynchronous work is
detachoperation creates a new, detached task that is completely independent of the code that initiated the
detach: the closure executes concurrently, is independent of any actor unless it explicitly opts into an actor, and does not inherit certain information (such as priority).
Swift’s Unicode.Scalar.Properties struct includes many useful property checks for scalars, such as
isHexDigit, etc. I think including a new
isPrependConcatenationMarkproperty check would also be useful, corresponding to the Prepend_Concatenation_Mark property listed in the Unicode Standard.
Swift on the Server Workgroup meetings:
Asynchronous Swift code needs to be able to work with existing synchronous code that uses techniques such as completion callbacks and delegate methods to respond to events. Asynchronous tasks can suspend themselves on continuations which synchronous code can then capture and invoke to resume the task in response to an event.