Here’s a fresh update on everything going on in Swift in open source. Like every other week, really! It continues to be a pleasure being able to write and share this newsletter with you, keeping a digestable overview of changes.

Enjoy the brief!

Interested in sponsoring Swift Weekly Brief? Learn more here.

Starter tasks

  • SR-13255 [swift-driver] Darwin-specific argument validation
  • SR-13385 [Compiler] Improved diagnostics when using instance methods before initialization
  • SR-13388 [Compiler] Add Fix-Its to “override” mismatch
  • SR-13445 [Compiler] Replace uses of the word “accessor” in diagnostics with user-facing terminology

News and community

Steve Canon shared update notes for Swift Numerics 0.0.7.

Ben Cohen wrote some thoughts on deprecating AnyCollection, allowing for performance optimizations going forward.

Commits and pull requests

Mike Ash merged a pull request reimplementing protocol conformance caching, improving its performance.

[..] checks should be 10-100x faster once cached

🏎!

Accepted proposals

SE-0287: Extend implicit member syntax to cover chains of member references was accepted.

The feedback was overwhelmingly positive. Accordingly, SE-0287 is accepted.

Proposals in review

SE-0288: Adding isPower(of:) to BinaryInteger is under review.

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

Doug Gregor wrote a second proposal pitch for function builders.

It has been a long time since the first function builders pitch last year. Since then, we’ve completely transformed the implementation to get the support for language constructs like local let bindings, if let, switch, and if #available that we wanted, as well as implementing a new semantic model that makes efficient type checking possible.

Last year’s pitch thread involved a lot of potential expansions to the idea of function builders—things like virtualizing execution, or programmatically inspecting the AST—to broaden their applicability into other domains. None of those have made any visible progress. On the other hand, people have built a number of cool DSLs on top of the experimental function builders implementation, so we feel pretty good that we have a well-rounded feature that makes Swift more expressive. The ad hoc nature of the interaction between the language and function builder types allows us to treat the system we have as the basis, which can be further extended when those ideas come to fruition.

To that end, here is a revised proposal for function builders.

Daryle Walker brought up a question surrounding AnySequence / AnyCollection conversion.

I’m working on something involving AnySequence. I saw AnyCollection and its bi-directional and random-access counterparts while reading Apple’s docs. I noticed that the collection versions can all cross convert (unconditionally when going towards a base, fail-able when going away from a base), but the conversion set doesn’t include AnySequence. Any reason why? In the past few years since the older post, has any new Swift features changed the landscape? Does ABI stability mess anything up?

Peter Adams shared meeting notes for the Swift on the Server workgroup August 5 meeting.

James Campbell brought up a compiler improvement for enum cases with @available markers.

Given the following enum:

enum Labels: String {
    
    case foo
    case bar
    case baz

    @available(iOS 14, *)
    case notAvailableYet
    
}

With the following code:

@avaliable(iOS14, *)
func foo() {
}

switch label {
case .notAvailableYet:
    foo()
}

The compiler will force you to wrap the call-site for foo() with a availability check even that case is already for an enum which is marked as only being available for the same iOS version.

It would be great if the compile could automatically synthesise this availability check as part of the case statement so it won’t execute that case (If rawValue was used to dynamically select that enum then perhaps there could be a runtimes error)

Karl pitched a proposal for a Swift dynamic loading API.

I’ve been wondering if there’s any appetite for a Swift dynamic loading API. Basically a Swiftier version of dlopen and dlsym, maybe making use of reflection metadata to support more kinds of queries on loaded modules. There is precedent for it: Java has its own ClassLoader API and Go also supports plugins.

This could allow for richer interfaces than are currently practical using C interop and dlsym.

Jorge Revuelta pitched a proposal for “typed throws”.

throws in Swift is missing the possibility to use it with specific error types. On the contrary Result and Future support specific error types. This is inconsistent without reason. The proposal is about introducing the possibility to support specific error types with throws.

Ariel Bogdziewicz pitched a proposal to allow protocols to conform to other protocols.

My custom container implemented as

let listeners = Listeners<MyListener>()

raises an issue:

Value of protocol type 'MyListener' cannot conform to 'ListenerProtocol'; only struct/enum/class types can conform to protocols

It would be nice to make it working for protocols.

Finally

The Corgi Core Team. 🐶