Summer is almost over and it seems that the Swift community is getting ready for some big product announcements later this year. Nevertheless we had quite an intense last two weeks in the Swift.org open source projects.

有兴趣赞助 Swift Weekly Brief？点击这里

Starter tasks

• SR-11295 [Compiler] There should be a warning for unnecessary casts
• SR-11321 [SwiftPM] generate-xcodeproj does not generate relative search paths correctly

Podcasts

In the latest Swift by Sundell podcast, John Sundell, Benedikt Terhechte and Bas Broek dive into the new APIs and features in iOS 13 and iPadOS, as well as Swift 5.1.

News and community

Cory Benfield gave a heads up that if we are using SwiftNIO HTTP/2, we need to upgrade as soon as possible.

All swift-nio-http2 users, please update to swift-nio-http2 version 1.5.0 urgently.

A number of HTTP/2 server implementations have been discovered to be at risk of a number of different denial of service attacks. SwiftNIO HTTP/2 has been affected by several of these vulnerabilities. This disclosure covers all of them.

All SwiftNIO HTTP/2 versions between 1.0.0 and 1.4.0 inclusive are affected.

Julian Lettner shared a blog post about the thread sanitizer for Swift on Linux. If you have any questions head down to the forum discussion.

The Swift language guarantees memory safety in single threaded environments. However, conflicting accesses in multithreaded code lead to data races. Data races in Swift cause unexpected behavior and can even lead to memory corruption, breaking Swift’s memory safety. Thread Sanitizer is a bug-finding tool that diagnoses data races at run time. It instruments code during compilation and detects data races when they happen during execution.

Bruno Rocha wrote a great blog post on advanced lldb tricks for Swift - injecting and changing code on the fly.

Ole Begemann tweeted about autodiscovery of test methods on Linux and other non-Darwin platforms. It was introduced in pull request 2174.

Autodiscovery of test methods on Linux* is now a thing in recent Swift 5.1 snapshots. You should be able to delete LinuxMain.swift and run your tests with:

swift test --enable-test-discovery

Joe Groff tweeted that now you can implement the wrapper as a static subscript with access to self. This was done in pull request 25884 by Doug Gregor. Be careful and use this at your own risk!

Slava Pestov tweeted that we could learn from JavaScript that delayed parsing is a cool trick.

Delayed parsing is a cool trick. I know JS implementations do it too. The idea is you can skip building AST for some parts of a source file. In order to correctly parse code following a delayed range, you still have to run the lexer - but it suffices to just count matching braces

Commits and pull requests

Jonas Devlieghere merged a pull request that moves Xcode support to C++14. It’s useful to mention that LLVM and clang are now compiling with C++14 as well. You can discuss it here.

Doug Gregor created a pull request that will simplify one-way constraints to Equal.

Proposals in review

A new proposal from the Swift Server Workgroup about an incubation process change. Feedback period will be till August 29.

When using Unsafe in Swift, Swift becomes as “safe” as C(++). Research shows that about 70% of the security vulnerabilities are related to memory safety issues.

Swift and SwiftNIO try to offer programmers fast and safe APIs which should mostly make the use of Unsafe constructs unnecessary. If that is not the case, we appreciate feature requests to add API allowing to use safe APIs to the respective projects.

Swift Forums

The Swift on Server Workgroup had a meeting on July 25th, 2019 and Tanner Nelson shared notes.

Ben Cohen started a discussion whether it’s appropriate to provide a default implementation relying on ObjectIdentifier. This is a continued discussion from SE-0261: Identifiable Protocol.

To set expectations clearly: the proposal has been accepted and the default implementation will ship in Swift 5.1. There is no possibility of it being removed from that release, given the point we are at in the convergence of 5.1, regardless of the direction of this discussion.

Michael Gottesman shared news that stdlibCore now always lowers ownership after running the diagnostic passes.

…I flipped the switch causing stdlibCore to always lower ownership /after/ running the diagnostic passes. This is a large milestone for ownership in general since this is the first time we have exposed some passes downstream of the Mandatory Inlining to ownership in the build itself (vs tests). It will ensure that changes in tree do not break basic functionality when we are in this mode (something that I have run into).

Suyash Srijan pitched a proposal about didSet semantics.

This proposal aims to make a small change to the semantics of didSet, so that the call to the property’s getter is skipped if the user does not refer to the oldValue in the body of the observer. It also aims to make another change, where the lack of a willSet and the presence of a unparameterised didSet could allow for modifications to happen in-place.

Saleem Abdulrasool shared that now you can use the Swift Package Manager on Windows.

Morten Bek Ditlevsen started a discussion about future directions of Property Wrappers.

Suyash Srijan started a discussion about class-constrained protocol extensions that have incorrect mutatingness.

Kelvin Ma posted a question: why aren’t some evolution proposals moving forward?

I’m opening this thread because one of my proposals, Synthesized Comparable for pure enumerations, has been sitting with its swift evolution PR open for nearly a month with no action from core team members who would have the authority to bring it to review. the proposal text is finished, raised issues have been addressed, and its implementation branch has been untouched for about two months now. By all means, the proposal has fulfilled all the requirements to go to community review (except for CI tests, which can only be triggered by members with write-access), yet still, no review has been scheduled.

Marc Rasi shared an idea about building .swiftmodules for SourceKit

I’m working on adding SourceKit to Google’s internal source tooling. The architecture is a server that runs one instance of SourceKit per user, and uses those instances of SourceKit to serve requests from IDEs.

To make this work on code that imports modules, I need to give SourceKit access to the appropriate “.swiftmodule” files.

Ben Langmuir noted that a preview version of SourceKit-LSP is now included in the nightly toolchain downloads for both Swift 5.1 Development and Trunk Development (master).

Dale Buckley started a discussion about default protocol implementation inheritance behaviour. The original bug was reported here.

Finally

It is summertime now, need to do some gardening.