Issue #159 07 May 2020
Written by: Kristaps Grinbergs
The last two weeks started quite slow, but now it seems that things are starting to heat up. Apple has released more information about WWDC 2020, announcing it will take off on June 22.
Also, Google Summer of Code 2020 students have been announced. They will be working on important and exciting projects for Swift over the summer, being mentored by the people at Apple!
Interested in sponsoring Swift Weekly Brief? Learn more here.
In episode 71 of the Swift by Sundell podcast, Dave Abrahams joins John Sundell to talk about Protocol-Oriented Programming and how to make the most out of the Swift Standard Library. Also, discussions on Swift’s overall design, why it puts such a strong emphasis on value types and protocols, and how it’s been influenced by other languages.
News and community
An announcement has been made about even more Linux platforms officially supporting Swift.
Development is open for Swift 5.2.4 for Linux, with a planned release at the end of May 2020.
Kenta Kubo tweeted how to use a SwiftPM package on Swift Playgrounds on iPad by using Working Copy and Textastic.
Commits and pull requests
The integrated REPL has been deprecated in favor of the LLDB REPL for a while, and the implementation had accumulated some amount of technical debt throughout the code base. Since most people don’t use it and are not even aware that it exists, we can remove it.
The amended proposal was received more positively. Several reviewers who had opposed the original proposal were now unreservedly in favor. Others supported the new proposal overall but expressed a preference for also allowing an argument label on the first closure.
However, many reviewers continued to oppose the amended proposal. Some reviewers expressed their dislike of trailing closures overall, or disputed the need to allow multiple trailing closures. The core team continues to believe, as we stated at the start of the second review, that the underlying motivation for the proposal is sound and changes here are merited. Other reviewers disliked the specifics of the change or felt that it was not tenable without allowing an argument label on the first closure or without substantial changes to the model for type-checking calls with trailing closures.
During the review, support was nearly unanimous for the memory model the proposal establishes, bringing Swift in line with the model standardized by C. The core team concurs with the review discussion on this subject, and would like to see a revised proposal that focuses on specifying the memory model. Guaranteeing a C-compatible memory model allows developers that currently wrap atomic primitives written in C and import them into Swift to rely on this continuing to work. This would also provide stable ground for building atomics packages outside of the standard library for experimentation and use by early adopters. The Swift project itself plans to develop one of these packages
Proposals in review
Hashableconformance for all tuples whose elements are themselves
Tuples in Swift currently lack the ability to conform to protocols. This has led many users to stop using tuples altogether in favor of structures that they can them conform protocols to. The shift from tuples to structures have made tuples almost feel like a second class type in the language because of them not being able to do simple operations that should just work.
It would be desirable to simplify the use of executables that have been compiled with swift build and installing the binary, payloads and other requirements into either a global location usable by all users on the system, or make it available only to the current user.
This would simplify the distribution and usage of Swift-authored tools, as instructions for installing the software would be as simple as directing the user to type swift tool install.
newtypehas come up again and since I don’t have a specific pitch I thought I’d start some discussion outside of the older thread. Before diving into specific syntax or implementation details I think it would be good to gather ideas about what people want out of such a feature and what they feel is most important.
This proposal adds an attribute to allow Swift enumerations to opt-in to an extensible behaviour. This reconciles a feature mismatch between resilient and non-resilient dialects of Swift, and makes Swift enumerations vastly more useful in the public API of non-resilient Swift libraries.
There could also be an opportunity for us to eliminate the language dialect here in Swift 6, and make it so that the next breaking change of the language always defaults enums to non-frozen behavior in all modules.
I read these kind of things very frequent in the last couple weeks. That makes me wonder, what kind of breaking changes are considered/allowed in Swift 6? There are a couple other things that come to my mind that would require a breaking change to be really fixed / work.
- Give the user an idea of what they should expect - is the build system initializing? Does the build system recognize the file? Is (pre)building still required before full functionality can occur?
- This will increased perceived reliability as long as these statuses are accurate and clear
- SourceKit-LSP can also change behavior based on these states, e.g. potentially hold back diagnostics if the build system still needs to prebuild.
- Make the clangd/sourcekitd loading state clear. This helps isolate build system vs. compiler issues and lets the user know the compiler is working (even if we can’t provide progress estimates)
mongo-swift-driveris a client library for using MongoDB from Swift. Its module
MongoSwiftprovides a SwiftNIO-based asynchronous API for interacting with the database. The core type,
MongoClient, maintains a pool of connections to servers in a MongoDB deployment and provides an interface for querying, inserting, and updating data in the deployment. In addition, the client handles authentication, TLS, topology monitoring, and automatically retrying failed commands. The driver also contains a BSON implementation allowing users to create and manipulate MongoDB documents and to convert between documents and native Swift types.
SE-0102 introduced the
Nevertype, an enum with no cases, as a way of conveying to both the compiler and user that a function cannot return by normal means. Instead, a
Never-returning function might throw an error, trap, or simply never terminate. Over time, the type’s uses have expanded to model other “impossible” situations. For example, thanks to SE-0215, which conformed Never to Error, one can construct a
Result<String, Never>which is guaranteed to represent a success state
SR-12113 asks that we codify the behavior of the
maxmethods on sequences into a guarantee in the documentation. Unfortunately, the current behavior of the max methods is inconsistent with other places in the standard library that identify the maximum of two or more inputs, when there is more than one “maximum” value.
Specifically, the sequence method returns the first of several maximum elements in the sequence, while the other APIs (the max free functions and the
FloatingPoint.maximumstatic methods) return the last of the maximum values. In general, this difference behavior isn’t noticeable, but for class instances it’s observable through instance identity, and when using the predicate-based method can be observed through whatever properties aren’t included.
Result types with a success type of Void are commonly used when no further information about the result of the operation are required – other than to know it was successful. In these cases, it is necessary to return a Result via