Issue #169 24 Sep 2020
Written by: Kristaps Grinbergs
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.
- SR-13573 [SwiftSyntax] Fix Spelling of
- SR-13572 [Standard Library] investigate removal of
- SR-13571 [Standard Library] build release and debug variants of
News and community
Commits and pull requests
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.
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
Namely, if a property wrapper has a mutating getter but a non-mutating setter, and the
didSetbody 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
didSetbody does not refer to
oldValue, the setter is made non-mutating.
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.
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
_modifycoroutine 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:
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.