An update on the Swift Weekly Brief from Bas:

After Jesse moved on to different project after issue #100, I’ve decided to move on to different projects now, too. I’ll stick around for issue 170, but that’ll be my last. You can read my blog post for more details. It’s been an absolute pleasure contributing to and helping out with this project, working with Jesse and Kristaps, as well as all other contributors and authors.

I took over the newsletter from Jesse as I wanted to keep this valuable research afloat — helping more than 10.000 subscribers and followers to stay up-to-date with what’s happening in the Swift.org and other Apple open source projects.

As Jesse said in issue 100, this still stands and I hope this project will continue through contributions from the community:

Gladly Kristaps will be taking over and will remain as the main contributor for Swift Weekly Brief. More contributors however are welcome. If you are interested, please get in touch!

All the best, Bas

In other news…

The last two weeks were full of surprises and new stuff. Xcode 12 was officially released along with Swift 5.3 as well as Swift docker images. The Swift repository moved to having a main branch as its default.

It did not stop there and as a surprise Swift on the Windows landed.

Interested in sponsoring Swift Weekly Brief? Learn more here.

Starter tasks

  • SR-13573 [SwiftSyntax] Fix Spelling of CustomReflecatbleTests.swift
  • SR-13572 [Standard Library] investigate removal of visualc module
  • SR-13571 [Standard Library] build release and debug variants of swiftrt.obj, swiftCore

Podcasts

In the latest episode of Swift Unwrapped, Jesse and JP talk about Swift 5.3.

News and community

Jordan Rose started a blog series about the Swift runtime. You can give your feedback in this forum thread.

Max Desiatov wrote a blog post about the state of Swift for WebAssembly in 2020 (and earlier).

Tryolabs shared a video - deep dive into Swift for Tensorflow.

Saleem Abdulrasool wrote a blog post introducing Swift on Windows.

Commits and pull requests

Doug Gregor merged a pull request that introduces the @actorIndependent attribute.

Karoy Lorentey opened a pull request that implements atomic strong references, which were a fun way to prove the versatility of the atomics API. Incidentally, they may also become a convenient default solution for memory reclamation in concurrent Swift data structures.

Doug Gregor merged a pull request that extends diagnostics and code completion to help guide developers toward implementing function builders.

Accepted proposals

SE-0288: Adding isPower(of:) to BinaryInteger was accepted.

Checking some mathematical properties of integers (e.g. parity, divisibility, etc.) is widely used in scientific and engineering applications. Swift brings a lot of convenience when performing such checks, thanks to the relevant methods (e.g. isMultiple(of:)) provided by the standard library. However there are still some other cases not yet supported. One of those useful checks that are currently missing is to tell if an integer is power of another, of which the implementation is non-trivial. Apart from inconvenience, user-implemented code can bring inefficiency, poor readability, and even incorrectness. To address this problem, this proposal would like to add a public API isPower(of:), as an extension method, to the BinaryInteger protocol.

Swift Forums

Slava Pestov discussed how to clarify the behavior of SE-0268 with a mutating getter.

Namely, if a property wrapper has a mutating getter but a non-mutating setter, and the didSet body refers to oldValue, the synthesized setter has to be mutating as well, since it calls the getter to load oldValue. However in the current implementation, if the didSet body does not refer to oldValue, the setter is made non-mutating.

Ben Cohen addressed an issue with unimplemented evolution proposals.

The core team has recently been discussing of a number of proposals that have been accepted but not implemented. You can see a list of these proposals on the evolution dashboard.

The core team feels that it’s important to avoid a situation where evolution proposals remain accepted but unimplemented for long periods of time. The main cause of this was eliminated through the requirement that proposals come with an implementation prior to review. Some unimplemented proposals pre-date this rule. Another cause can be proposals that are implemented, but the implementation is not quite ready for production use. Finally, several proposals are mostly implemented, except for some small portion that proved problematic or was missed.

Jonathan G started a thread about updating Swift.org API guidelines regarding get in function names.

I think this current situation is a direct consequence of the fact that our Swift API guidelines do not explicitly say not to use get for functions that return a value.

So my pitch is that we should update the Swift.org API design guidelines with the same basic guidelines about the use of get in method names as was found in the Cocoa guidelines

Lily Ballard wrote a post explaining an issue with Xcode 12 having unexpected consequences of SE-0268: new simple _modify semantics. In short, code that previously ran just fine will now fails at runtime with a simultaneous access error.

The issue lies in interactions with optional chaining and an assignment expression that references the property. In particular, with the non-simple version, the synthesized _modify coroutine yields a reference to a stack-allocated copy of the value, and therefore does not hold memory access on the property during the yield. But in the new version, it holds [modify] [dynamic] access during the yield. Without optional chaining this is generally fine, as the right-hand side of the assignment is evaluated before the _modify is invoked, but with optional chaining it has to defer evaluating the right-hand side until it’s verified that the property’s value is nonnull.

The Swift Server Work Group held two meetings and shared notes:

Saleem Abdulrasool started a thread discussing about enabling static linking on Windows.

Windows has definitely come a far way from when it started. However, one feature that still is not available on Windows is static linking. Everything currently requires dynamic linking, which is a bit unfortunate. Although, technically, the Microsoft linker can resolve the imported symbol, it comes at a cost (binary size and runtime overheads, and unnecessary warnings). It would be wonderful to get this issue resolved. Even then, it results in over-exposure of the interfaces, which is another source of issues. However, going the other way has even bigger problems, and given that dynamic linkage is generally preferable, it is what I focused on initially.

Slava Pestov started [a discussion] about clarifying scoping behavior with local functions.

Finally

Boolshit

Singing while working