Issue #155 12 Mar 2020
Written by: Bas Broek
Another fortnight passed by, another Swift Weekly Brief. Enjoy!
Interested in sponsoring Swift Weekly Brief? Learn more here.
Podcasts
In episode 85 of Swift Unwrapped, Jesse and JP talk about Swift on Windows and other news.
News and community
Nate Cook wrote a blog post on Swift.org, announcing ArgumentParser, an open-source library that makes it straightforward — even enjoyable! — to parse command-line arguments in Swift.
Swift 5.1.5 has been released.
Commits and pull requests
Doug Gregor merged a pull request
that adds switch statement support to function builders!
In that pull request, Doug pushed a commit after a code review from John McCall who noted a subtle omission in constraint generation that affected the semantics of switch statements in function builders.
David Smith and Tim K merged a pull request that provides a speedup for bridging ObjC collections containing NSStrings.
Kuba (Brecka) Mracek merged a pull request, upstreaming arm64e support for Swift.
Also:
this means we finally won’t have a billion arm64e merge conflicts every single week
Pretty neat!
Proposals in review
SE-0280: Enum cases as protocol witnesses is under review.
The aim of this proposal is to lift an existing restriction, which is that enum cases cannot participate in protocol witness matching.
Currently, Swift has a very restrictive protocol witness matching model where a protocol witness has to match exactly with the requirement, with some exceptions (see Protocol Witness Matching Manifesto).
SE-0279: Multiple Trailing Closures is under review.
Since its inception, Swift has supported trailing closure syntax, which is a bit of syntactic sugar that makes passing closures more ergonomic. Trailing closures have always had two restrictions that limited their applicability. First, that any call is limited to a single trailing closure, making the feature awkward or even unusable when an API has more than one callback. This limitation was noticed very early on in Swift’s lifetime as “the” problem with trailing closure syntax. Second, that a trailing closure argument does not provide an argument label, which can lead to call sites that are less clear. This proposal removes both restrictions by providing an unambiguous syntax for providing multiple, labeled trailing closures in a call, leading to clearer and more consistent code.
Swift Forums
Joe Groff provided an update on SE-0057.
The core team is continuing to review the status of older proposals in order to bring their status into line with reality. SE-0057 introduced the ability for Swift to import Objective-C lightweight generics as compile-time generic types in Swift, with some limitations due to the type-erased nature of generics in Objective-C. Although this proposal was accepted, and claimed to be in the “Implemented” state, one aspect of the proposal was not implemented. The originally accepted proposal described an informal protocol by with Objective-C classes could optionally provide generic argument information back to Swift.
However, that informal protocol was never implemented. The Core Team has decided to withdraw this aspect of the proposal.
Alejandro Alonso pitched a proposal
to have tuples conform to Equatable, Comparable, and Hashable.
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.
Varun Gandhi raised a question about ABI compatibility and language proposals.
One implication of SE-0280 is that it introduces a way into the language in which one can break binary compatibility without breaking source compatibility. More specifically, one can make a property witness and replace that with an enum case (which also acts as a witness) but this would break binary compatibility (the other way round breaks source compatibility, as a client may be pattern-matching on the enum case you’re getting rid of). There are already other ways in which this happens today (such as with SE-0267), but this proposal adds one more way this can happen.
Compared to most other languages, Swift has a much better story around binary compatibility. Part of the reason why I really like the design is that (in the majority of cases) changes that “should” not break binary compatibility do not break binary compatibility. To reappropriate the phrase, fast and loose reasoning is morally correct with regard to binary compatibility – (in the majority of cases) source-equivalent code is ABI-equivalent.
If we add more cases like this, that adds an extra wrinkle that users need to be wary about. I suspect that a large fraction of users of this feature will probably not be affected by this change. A small percentage of people might be affected: should we have a backup plan for them?