Issue #190 29 Jul 2021
Written by: Kristaps Grinbergs
The slow summer trend is also continuing these past two weeks. Despite that, there are a bunch of accepted proposals and some fresh ideas on the Swift forums.
As always, I appreciate your support. Now let’s get to the news.
From August 2nd to 8th you can join a FREE crash course for iOS devs who want to achieve an expert level of technical and practical skills – it’s the fast track to being a complete senior developer!
- SR-14941 Introduce compiler warning for leading-zero octal notation
- SR-14943 [Compiler] Fix-it for changing unsafeBitcast to unsafeDowncast should be more narrow or removed
- SR-14971 [Compiler] Spurious error after wrapped ‘var’ declaration without type annotation.
News and community
Great article about using tuples in complex sorting operations in Swift.
Feedback from the review was positive, and mostly focused on further exploration of making
Nevera true bottom type, or similar alternatives to expanding the list of protocols
Neverconforms to in a systemic manner. The core team acknowledges this is an interesting design space and encourages follow up proposals exploring it.
A significant area of feedback during the review was that of the creation of implicit suspension points when an
async letvariable is not awaited on a path that exits a scope that is not itself an awaited function. This creates an exception to the rule that suspension points are always marked with an
After thorough discussion of the alternatives to implicit suspension points, the core team feels that language-level solutions add more complexity than is warranted to eliminate implicit suspension points.
The core team acknowledges that this exception may have more impact in practice than can be reasoned about without real-world use. There is an opportunity to react to real-world feedback in Swift 6 by tightening up the model around implicit awaits if it turns out that they are harmful in practice (although it is not currently the intention to do so).
The proposal authors have added descriptions of other solutions and their downsides to the alternatives considered section of the proposal. This section also has additions covering other alternatives discussed during the review, such as the use of property wrappers for a partial library-level solution.
Support for the added functionality was unanimous; there was some discussion about whether the proposal might be better titled “type placeholders” or “inferred types”, but that would not affect the behavior of the feature within the language. Thanks to everyone who participated in the review!
The proposal is accepted. After much discussion, Core Team has decided to retain the
AsyncThrowingStreamnames as proposed.
The feedback from the review highlighted further refinement that can be done to the ergonomics of the proposed solution including the templating system. For example, the proposal can make it clearer why a new command is desired compared to enhancing the existing package init command, and explore a templating system that supports for multi-template-single-repo and programatic interfaces.
The proposal authors are encouraged to consider these alternative design ideas, and pitch a modified version of the proposal to the community.
While migrating a project to the new async features of Swift I constantly needed a mechanism for a synchronization point based of the availability of some value. As far as I can tell, currently there is nothing in the stdlib to cover this.
Basically, this is something like an ‘AsyncSequence’ with only 1 value.
The idea is a new feature for multi-line string literals that allows the user to specify what format the nested content should conform to. Swift would provide a String.Syntax enumeration that would allow the programmer to choose amongst a wide range of existing formats to designate the string content as conforming to.
I’d like to make the command line interface more appropriate for direct, interactive use by humans, while keeping automation use cases available. I propose to rework the CL tools in the following ways:
- Give users direction in accomplishing their Swift tasks at the command line, providing choices for high level tasks and > * clarification about what to do next where possible.
- Progressively disclose flags and options, keeping text focused on the current task.
- Make the command line aware of context so it can infer the right action for impactful cases.
- Continue to provide explicit invocations for all of the tasks we perform today.
@testableis a very useful feature, however I’ve recently had several bugs caused by accidentally accessing
internalsymbols, or rather, by forgetting to declare symbols in a framework
So, I’m wondering if it was a mistake to make
@testableallow access to all symbols with
internalvisibility, and whether it should be changed to just provide access to symbols that are explicitly marked with a special
For all other intents and purposes,
testablewould be identical to
internal. The only difference would be that
@testable importonly makes
testablesymbols accessible, all symbols marked as