Issue #47 17 Nov 2016
Written by: Bas Broek
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?
- SR-3174: The
#selectorkeyword 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
swiftcon 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
Commits and pull requests
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.
Ankit Aggarwal updated SwiftPM to enable whole-module optimization in release mode for Xcode projects.
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:
To introduce an “autopin” behavior to cover the problem Paul outlined where
pin --alleffectively needs to be “sticky” for any new dependencies which come into play.
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! 👏
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.
Functional Emoji is an ‘artisinal bot’ that posts funny statements using emoji and common functional programming statements like
filter. Some gems include: