This week the third beta of Xcode 9 (and thus Swift 4) was released, there are a couple of new proposals in review, and the IBM Runtimes compiler team announced a prototype JIT compiler for server-side Swift, which will be open sourced in the near future. This is super cool, but if I’m being honest I’m more excited about the potential enhancements to multi-line string literals. 😄
In other news, there are currently 15 accepted proposals for Swift 4 that have not been implemented. I’m sure many are in-progress, but it looks likely that some of these will be pushed to a future release.
Go from junior to senior developer in just a week, with the experts who have taught iOS from the very beginning.
- SR-5337: Improve diagnostic for
varin parameter position
- SR-5383: Display appropriate message when trying to build system module packages
- SR-5324: Better diagnostic when instance member of outer type is referenced from nested type
In Episode 19: WWDC Reactions, we share our thoughts on the announcements and events from the week. Better late than never! Listen to find out why we had to wait so long. 😄
News and community
New betas of Xcode 9 and Swift 4, and all the platform OSes are now available.
Some updates to the CODE_OWNERS.txt were made, so take note for when you need to find the right person to review your pull requests. Of note, Chris Lattner is still listed as being responsible for “everything in Swift not covered by someone else” — good thing he’s currently unemployed! 😉
Commits and pull requests
Arjun Nayini merged changes to the stdlib to make 0-ary tuples (that is,
()) conform to
Equatable. (SR-4172) Rejoice,
() == () will now compile. And it only took 3.5 months! 😅 Luckily, it did not require a formal swift-evolution review.
Jordan Rose made changes to the ClangImporter to prevent importing compatibility methods named
Swift.print. Amen. 🙌
As part of SE-0157, Doug Gregor added a new frontend flag,
-enable-recursive-constraints to disable the error about direct recursion within a protocol definition. The implementation of recursive protocol constraints is incomplete, but might be useful for experimentation.”
Philippe Hausler added benchmarks for common
NSString APIs that are exposed on
Bartek Chlebek implemented
OperationQueue.current in corelibs-foundation.
The proposal is accepted. There was a lively discussion about it, but in the end everyone seems to agree that this is the right thing to do.
As always, I’d like to thank you for your help in making Swift a better language.
Proposals in review
This proposal adds support for declaring the language standard for C and C++ targets in a SwiftPM package.
The C++ language standard is one of the most important build setting needed to compile C++ targets. We want to add some mechanism to declare it until we get the complete build settings feature, which is deferred from the Swift 4 release.
This proposal is a refinement of SE-0168 which introduces the ability to escape newlines in single and multi-line strings to improve readability and maintenance of source material containing excessively long lines.
Swift-evolution thread: Discussion thread
Escaping newlines in multi-line strings was removed from the SE-0168 proposal by the Core Team […]
Adding them to multi-line strings would have introduced an inconsistency with respect to conventional string literals. This proposal conforms both multi-line and conventional string construction to allow newline escaping, enabling developers to split text over multiple source lines without introducing new line breaks. This approach enhances source legibility. […] Incorporating a string continuation character is well founded, used in other development languages, and carries little risk of confusing naive users.
Younes Manton sent an email announcing a prototype JIT compiler for server-side Swift, created by a small group of developers from the IBM Runtimes compiler team:
Last year a small group of developers from the IBM Runtimes compiler team undertook a project to explore JIT compilation for Swift, primarily aimed at server-side Swift. The compilation model we settled on was a hybrid approach that combined static compilation via
swiftcwith dynamic compilation via a prototype JIT compiler based on Eclipse OMR. 
This prototype JIT compiler (targeting Linux specifically) functioned by having itself loaded by a Swift process at runtime, patching Swift functions so that they may be intercepted, recompiling them from their SIL representations, and redirecting callers to the JIT compiled version. In order to accomplish this we needed to make some changes to the static compiler and the target program’s build process.
(As for the prototype itself, we intend to open source it either in its current state [based on Swift 3.0 and an early version of OMR] or in a more up-to-date state in the very near future.)
And finally — babe of my existence. 😄