This week changes to branch management for the swift-LLDB repository were announced, as well as a new Swift Syntax and Structured Editing library! This library aims to expand on the functionality provided by SourceKit and sounds like it could enable tons of great new tooling for Swift. Apple also announced WWDC 2017.

Starter tasks

  • SR-3936: Provide a Fix It for errors such as “Computed property must have an explicit type”
  • SR-3882: @objc protocol conformance info isn’t recorded when a type conforms to a Swift sub-protocol
  • SR-3867: Improve diagnostics for labeled block without do

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

News and community

The engineering team at Airbnb shared their story on migrating to Swift 3. The post covers their approach to the migration, the impact of Swift 3 on binary size and build time (both regressed, unfortunately), and some issues to watch out for. It’s an interesting read and definitely highlights the risks and pain points that early adopters experienced. But hopefully that’s over now. 😅

Ole Begemann wrote an article on implementing a sorted array in Swift, a follow-up to objc.io’s Swift Talk #35. His post and the objc.io video provide a great in-depth look at how to write your own, efficient collections in Swift.

Apple announced WWDC 2017, which will be held June 5-9 in San Jose, CA.

Commits and pull requests

David Farler (@bitjammer) started the syntax structure editing library. (See below for more details.)

John Szumski (@jszumski) opened a pull request with an initial implementation of MassFormatter in corelibs-foundation.

Younes Manton (@ymanton) improved string comparison performance on Linux.

Ankit Aggarwal (@aciidb0mb3r) implemented tools version support in SPM. (SE-0152)

Philippe Hausler (@phausler) added additional conformances and functionality to NSRange.

Olivier Tardieu (@tardieu) added an unsafe String API discussion to String manifesto.

Accepted proposals

SE-0151: Package Manager Swift Language Compatibility Version was accepted for Swift 4.

There wasn’t much discussion on the mailing list, but we did receive some off-list feedback that was supportive. The proposal is accepted for Swift 4.

SE-0152: Package Manager Tools Version was accepted for Swift 4.

There wasn’t much discussion on the mailing list, but we did receive some off-list feedback that was supportive. The proposal is accepted for Swift 4.

Both proposals have already been implemented as well. 😄🎉

Mailing lists

David Farler sent an email announcing work on the Swift Syntax and Structured Editing library:

A truly modern compiler has to have excellent IDE and tools integration, as we have done through the SourceKit layer, providing code completion, documentation comments, syntax highlighting, and more. There’s no reason to stop there, so I’d like to announce work on the Swift Syntax and Structured Editing library, which will be growing in lib/Syntax in the coming weeks. The overall goal of the library is to provide a representation and a body of APIs for structured editing on Swift syntax.

The immediate goals of the library are to provide infrastructure for the Swift Migrator and for a first-class formatting tool, which we’ll be bringing to the open source tree and developing publicly.

Continue reading…

Chris Bieneman announced changes to LLDB branch management:

Over the last couple weeks we’ve been working on some changes to the branch management strategy for the Swift-LLDB repository. The goal is to have LLDB more closely align with the other projects forked from LLVM.org. We believe that making this change will simplify the contribution process for LLDB’s Swift support.

To this end, we are making the following changes:

LLDB has gained an upstream-with-trunk branch which will be auto-merged from LLVM.org’s LLDB/trunk. This branch will contain the best of both worlds. The latest and greatest from LLVM.org, and Swift support. This branch will pair to LLVM & Clang’s upstream-with-swift branches and Swift’s master-next.

LLDB has also gained a stable branch which will behave the same way as the LLVM & Clang stable branches, and should be used for most Swift compiler development. Additionally we have made the swift-lldb/stable branch the default branch on the GitHub repository, which matches the behavior of LLVM & Clang.

Continue reading…

David Hart started a discussion on the merit (or lack thereof) of the final, lazy, and fileprivate keywords. He argues that final has diminished value given SE-0117, that lazy will eventually be obsoleted by Joe Groff’s property behaviors proposal, and that fileprivate should be reverted (which has been discussed on the lists before). Matthew Johnson pointed out that final still brings a lot of value, and Chris Lattner noted that property behaviors won’t be implemented until at least Swift 5. The merit and utility of fileprivate is still in question, and the rest of the thread debates this. I would personally love to see SE-0025 reverted. In my experience fileprivate has become a burden rather than solving any tangible problems.

Finally

And finally — overflow and underflow. 😄