In this brief, a lot of swiftc crashes have been either fixed or identified, we discuss some proposals that are not yet in scope for Swift 4 Stage 1, and… well, let’s not spoil everything, shall we?

Starter tasks

• SR-3174: The #selector keyword gets confused by local variable names. A simple fix for this is to search for selectors after popping out of the local scope.
• SR-3175: The Swift “driver” is the program that runs when you invoke swift or swiftc on the command line. Its primary responsibility is to divide up work into several subprocesses (in parallel where possible). If one of these subprocesses terminates due to an exception, it would be helpful if the driver printed the signal number.
• SR-3207: Compilers should provide helpful errors, but they should never crash. With a little bit of C++, you can prevent a crash when Swift imports Objective-C code with incorrect nullability attributes, and instead a surface an error: “hey buddy, you can’t have a pointer be both nonnull and nullable.”

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

Commits and pull requests

Jacob Bandes-Storch added support to mark proposals as “in progress” on the Swift-Evolution proposal status site.

Slava Pestov opened a pull request with fixes for reflection. “This PR fixes two problems with the reflection library’s type lowering; enums without payloads would mess up layout of subsequent fields, and sometimes classes with superclasses had layout start at the wrong offset.”

David Jones from IBM submitted pull request to corelibs-foundation to improve JSON serialization performance on Linux.

Jonathan Anderson added support for FreeBSD in swift-llbuild.

Jacob Bandes-Storch fixed a bunch of crashes in swiftc.

@practicalswift also fixed a swiftc crash and identified a lot (!) of them. 😱

Ankit Aggarwal updated SwiftPM to enable whole-module optimization in release mode for Xcode projects.

Returned proposals

SE-0145: Package Manager Version Pinning was returned for revision.

Thanks to everyone who participated in this review!

Based on the pretty universal negative feedback, we are going to reject this proposal as is, and take it back for another round of revisions.

Our revised plan is:

1. To introduce an “autopin” behavior to cover the problem Paul outlined where pin --all effectively needs to be “sticky” for any new dependencies which come into play.

2. To make auto pinning on by default, with an explicit mechanism for projects to opt out.

And although there seems to not have been that much activity on the swift-evolution repository itself, check out this bunch of proposals that have been written — but are out of scope — for Swift 4 stage 1. There are quite a lot of interesting proposals to find there! 👏

Mailing lists

Please don’t hold your breath if you were expecting non-@objc optional methods in protocols. Chris Lattner:

We discussed this extensively in the Swift 3 timeframe, and I believe that the consensus was “no”: optional requirements are considered an Objective-C compatibility feature.

I don’t recall all of the discussion, but a major one would have to be that it is highly redundant with other language features we already have, and makes the design space of Swift APIs more complicated. If Objective-C didn’t already have them, we would never consider adding them to our protocol model.

Finally

Functional Emoji is an ‘artisinal bot’ that posts funny statements using emoji and common functional programming statements like map, reduce and filter. Some gems include:

[🍻,🍈,🍯].reduce(eat) => [💩]

[🇬🇹,🌍,🇻🇳].map(turn) => [🇭🇳,🌏,🇻🇳]