T-4 days for WWDC 2019! Oh yes, if somehow you missed that, it will start after the weekend. Looking forward to everything that’s new, including potential news about the future of Swift… fingers crossed!

For those that are attending, have an awesome time! And also make sure to say hello to Kristaps… he might have Swift Weekly Brief stickers to give out. Make sure to share pictures of where you put those :-)

Also, and I missed to include this two weeks ago, John McCall shared something I wanted to point out to all of you reading, and in particular, those directly involved with the Swift evolution process:

I’d like to thank the community for its patience and its commitment. I know we’ve had a lot of proposals recently, and some of them have been contentious, and it can be a lot of work to keep up with Swift Evolution. You really are appreciated; thank you for everything you do to help make Swift a better language.

Well said.

Starter task

• TF-449 [Standard Library] Conditionally conform Optional to Differentiable

News and community

Laurence Moroney and Chris Lattner talked about how Swift has grown beyond mobile development.

Will Lisac open sourced a set of Docker images for Swift on Raspberry Pi and other ARM devices.

Commits and pull requests

Joe Groff merged a pull request using the runtime hook mechanism to backward deploy a bug fix.

Erik Eckstein merged a pull request allowing Swift’s optimizer to constant fold key path accesses down into direct field accesses!

Accepted proposals

SE-0260: Library Evolution for Stable ABIs was accepted.

Stable library evolution has been a goal of the Swift project since its earliest days. SE-0260 builds on years of design and implementation effort, and it is as much an announcement of the success of that work as it is a proposal to change the language. Most of the formal content of the proposal is carved deep into the bones of the language; it could not be made any other way without grave consequences. All of this is to say that the basic outcome of this review is at least a little preordained.

Still, there are details that are worth debating. There were two basic categories of discussion in the review:

• Several reviewers provided concrete feedback on specific aspects of the new attributes and compilation modes proposed by SE-0260. On balance, the Core Team is satisfied with the language rules and names as proposed.

• There was quite a lot of debate about the exact process of developing and evolving stable libraries and the exact guarantees that Swift is making here. While SE-0260 lays out the most basic rules for stable libraries, there are many details like these that remain unsettled and which may have significant consequences for the evolution of the implementation. The Core Team feels that these details can be worked out in later proposals, and that any limitations on the implementation will provide adequate incentive to ensure that they are.

SE-0253: Callable values of user-defined nominal types was accepted with modification.

[..] the core team decided to accept the proposal, with the request to change func call() syntax to func callFunction(). The core team chose this direction because it retains the ‘call’ nomenclature established by SE-0216, but is a more verbose name that is less likely to already exist, or be accidentally used for an unrelated purpose.

After more feedback from the community, it was then further revised.

The Core Team discussed this and has decided to further revise the proposal to name the operator function func callAsFunction(). We are comfortable with enabling this functionality purely based on nothing more than the name of a function, and we are not persuaded that init and subscript (which both have substantially different semantic and syntactic rules and are not simply functions) provide important precedents here requiring a new declaration introducer.

Swift Forums

Pavol Vaskovic shared an update on benchmark performance.

I’m happy to announce that by the beginning of March 2018, a series of pull requests that applied legacy factor across the whole Swift Benchmark Suite (SBS) has lowered the workloads of individual benchmarks to execute in the 20–1000 μs range. My thanks go to Erik Eckstein for his patient review and guidance.

Point of this modification was to strengthen the resilience of our measurement process against accumulated errors caused by context switches that happen every 10 ms on macOS.

Dale Buckley pitched a proposal that introduces a removeAll(at:) function.

When dealing with collections of data, there are often times where it is required to remove multiple elements from a collection at different indices within the same operation. There are some common mistakes that can lead to unperformant and buggy code when presented with this task. This proposal intends to provide a simplified method to perform this operation in a safe and performant way.

Doug Gregor shared a revised pitch for property wrappers.

I’ve revised the property delegates proposal again, albeit under a more descriptive name “property wrappers”.

• The name of the feature has been changed from “property delegates” to “property wrappers” to better communicate how they work and avoid the existing uses of the term “delegate” in the Apple developer community

• When a property wrapper type has a no-parameter init(), properties that use that wrapper type will be implicitly initialized via init().

• Support for property wrapper composition has been added, using a “nesting” model.

• A property with a wrapper can no longer have an explicit get or set declared, to match with the behavior of existing, similar features (lazy, @NSCopying).

• A property with a wrapper does not need to be final.

• Reduced the visibility of the synthesized storage property to private, and expanded upon potential future directions to making it more visible.

• Removed the restriction banning property wrappers from having names that match the regular expression _*[a-z].*.

• Codable, Hashable, and Equatable synthesis are now based on the backing storage properties, which is a simpler model that gives more control to the authors of property wrapper types.

Saleem Abdulrasool announced Swift support in CMake!

I have been working with upstream to integrate Swift support into CMake with the Ninja generator so that it can be integrated into existing projects much more conveniently. I would like to announce that the last of the initial set of changes needed to support Swift in CMake have been merged now into CMake and I expect that the next major release of CMake (3.15) to include the Swift support.

… as well as Swift REPL on Windows!

I have gotten the REPL to the point where it now runs on Windows! There are some improvements to be made still, primarily in the application of Data Formatters. However, the expression evaluation appears to work now and overall. If there are people who would like to get involved in the Windows port on the lldb side - this provides an excellent opportunity to delve into lldb. It also can expand easily into the compiler side if you start looking at the AST side of things.

Finally

The real “Objective-C without the C” 🦕