Over the last two weeks we have seen a lot of proposals that have been discussed (and accepted), and it is likely we will see many of these proposals being released in either Swift 4.2 or Swift 5.

Starter tasks

• SR-7445 [Compiler] Call Expressions Need Better Assignment Diagnostics
• SR-7398 [Compiler] Preserve availability on ObjC subscript getters and setters

Submit a task by sending a pull request or opening an issue.

Swift Unwrapped

In Episode 53 Jesse and JP discuss Swift for Tensorflow, which was announced in a talk by Chris Lattner at TensorFlow Dev Summit 2019.

In Episode 54 Jesse and JP discuss some of the recent proposals on Collection and Sequence.

News and community

Slava Pestov wrote a blog post on some of the less-visible improvements in Swift 4.1.

Brian Gesiak wrote a blog post on how the Swift compiler emits diagnostics.

Commits and pull requests

Pavel Yaskevich merged a pull request that makes progresson fully implementing SE-0110: Distinguish between single-tuple and multiple-argument function types.

Slava Pestov merged a pull request to improve the Swift Intermediate Language (SIL)’s deserialization in -Onone mode — by 25% on a large project with batch mode! 👏

Accepted proposals

SE-0201: Package Manager Local Dependencies was accepted.

Feedback was positive, and the proposal is accepted. Thanks to everyone who participated!

SE-0205: withUnsafePointer(to:_:) and withUnsafeBytes(of:_:) for immutable values was accepted.

The review of this proposal is now over and the proposal has been accepted.

Thanks for everyone for participating in the review.

SE-0206: Hashable Enhancements was accepted with revisions.

init(seed:)’s behavior may be misleading to users who expect it to enable deterministic hashing, and has no real benefit over a collection implementation seeding the hasher directly with combine calls.

[..] the many combine(bits:)overloads on Hasher that take fixed-sized integers don’t need to be public API.

The core team recommends that Hasher.finalize() be made a __consuming nonmutating method instead of a mutating method that invalidates the Hasher value.

Thanks again to everyone for participating in the review!

SE-0208: Package Manager System Library Targets was under review and consequently accepted.

This proposal introduces a new type of target “system library target”, which moves the current system-module packages feature from package to target level.

The package manager currently supports “system-module packages” which are intended to adapt a system installed dependency to work with the package manager. However, this feature is only supported on package declarations, which mean libraries that need it often need to create a separate repository containing the system package and refer to it as a dependency.

Our original motivation in forcing system packages to be declared as standalone packages was to encourage the ecosystem to standardize on them, their names, their repository locations, and their owners. In practice, this effort did not work out and it only made the package manager harder to use.

---

Feedback was positive, and the proposal is accepted. Thanks to everyone who participated!

SE-0209: Package Manager Swift Language Version API Update was under review and consequently accepted with revisions.

This proposal changes the current Package.swift manifest API for declaring for Swift language versions from freeform Integer array to a new SwiftVersion enum array.

The Swift compiler now allows 4.2 as an accepted value of Swift version flag (-swift-version). The swiftLanguageVersions API in Package.swift currently accepts an integer array and we need to update this API in order for packages to declare this language version if required.

---

Feedback was positive, and the proposal is accepted with revisions. Thanks to everyone who participated!

We considered making SwiftVersion a struct which conforms to ExpressibleByIntegerLiteral and ExpressibleByStringLiteral. However, we think the enum approach is better for several reasons:

• It is consistent with the C/C++ language version settings.
• The package authors can easily tell which versions are available.
• The package authors don’t need to concern themselves with how to spell a valid version.

Extended proposals

The review of SE-0202: Random Unification was extended to get feedback on its design.

The nature of the generator API implies that the generators must be reference-y, since they aren’t passed inout to functions like shuffle, but aren’t required to be reference types.

The team thinks making the random(in: Range<T>) family free functions, rather than static methods on T, may help with discoverability.

The team felt that Collection.randomElement would work better than Collection.random. Unlike .first or .max, the word “random” doesn’t noun well, so adding “Element” improves readability.

The core team believes it would be better to leave implementation details of the default source to the individual platforms, rather than defining the implementation for each platform as part of the proposal.

Swift Forums

Erica Sadun pitched a proposal to introduce keywords in protocols that help eliminate bugs.

We’d love to know what you think of our idea, which is to introduce “role” keywords. Roles allow the compiler to automatically check the intended use of a extension member definition against its protocol declarations, and emit errors, warnings, and fixits as needed.

Erica also shared some thoughts about adding a CountedSet to Swift.

I’m looking to take the community temperature about adding CountedSet to Swift Foundation/Standard Library.

Joey KL pitched a proposal to rename protocols that use Self or associated types to “constraints”.

There are two different types of protocols in Swift and they behave completely differently. Normal protocols are like any other type, use dynamic dispatch and allow for heterogenous mixtures of different implementations (similar to objects that inherit from the same base class). On the other hand, constraint protocols (distinguished only by having an associatedtype, or even more subtle, just using Self) use static dispatch, can never be used like a type, and can only be used to restrict which real types can be used for a generic function or new concrete type.

Finally

Swift’s goal really is world domination… 🏎