Wow, what a week! Today is the final day of WWDC 2017. Swift 4, which is bundled with Xcode 9, has been released in its first developer beta. Xcode and Swift both have a number of huge improvements and new features — it’s a fantastic release. So far, the community response has been really positive. Congrats to the Xcode, Swift, and dev tools teams at Apple!

有兴趣赞助 Swift Weekly Brief？点击这里

Swift Unwrapped

Episode 14: What’s new in Swift, Part 1

We discuss some of the new features and improvements in Swift 4!

News and community

Apple announced that Swift Playgrounds is gaining support for programming toy robots and drones. They are partnering with a number of companies, like Lego, Sphero, and many more. This is pretty amazing and looks super fun. You can find a video here.

Erica Sadun’s book, Swift Style, is on sale this week.

objc.io has released a new book, Optimizing Collections. Written by Károly Lőrentey, the book is about writing very efficient custom collections in Swift.

Xcode 9 beta and new SDKs have been released.

WWDC videos on Swift

Commits and pull requests

Robert Widmann merged changes to fix some undefined behavior — fixed using Xcode’s new undefined behavior sanitizer (UBSan).

Roman Levenstein make some minor tweaks to reduce the code size of the Standard Library by 1.5 percent!

The Swift Server APIs Working Group has published a new repository for the development of cross-platform HTTP APIs.

Ben Cohen requested a pick in the swift-4.0-branch for his substring comparison performance improvements. Nate Cook also picked some dictionary improvements into swift-4.0-branch. There have been a number of picks into Swift 4 already, hopefully the others that have been requested make it in soon. We should see these improvements in the upcoming betas.

Slava Pestov fixed a handful of crashers. 👏

Proposals in review

SE-0180: String Index Overhaul by Dave Abrahams is under review

Today String shares an Index type with its CharacterView but not with its UTF8View, UTF16View, or UnicodeScalarView. This proposal redefines String.UTF8View.Index, String.UTF16View.Index, and String.CharacterView.Index as typealiases for String.Index, and exposes a public encodedOffset property and initializer that can be used to serialize and deserialize positions in a String or Substring.

[…]

The result is a great deal of API surface area for apparently little gain in ordinary code, that normally only interchanges indices among views when the positions match up exactly (i.e. when the conversion is going to succeed). Also, the resulting code is needlessly awkward.

[…]

All String views will use a single index type (String.Index), so that positions can be interchanged without awkward explicit conversions.

Continue reading…

Mailing lists

Ted Kremenek sent out an update about the to-be-open-sourced refactoring tools and other announcements at WWDC:

This afternoon at WWDC we announced a new refactoring feature in Xcode 9 that supports Swift, C, Objective-C, and C++. We also announced we will be open sourcing the key parts of the engine that support file-level transformations, as well as the compiler pieces for the new index-while-building feature in Xcode.

We will be releasing the sources in stages, likely over the next few weeks:

  • For the refactoring support for Swift, there are some cleanups we’d like to do as well as some documentation we’d like to author before we push these sources back. Argyrios Kyrtzidis and his team from Apple will be handling that effort.
  • For the refactoring support for C/C++/Objective-C, these are changes we’d like to work with the LLVM community to upstream to the LLVM project. These will likely be first staged to the swift-clang repository on GitHub, but that is not their intended final destination. Duncan Exon Smith and his team from Apple will be handling that effort.
  • We’ll also be open sourcing the compiler support for indexing-while-building, which include changes to both Clang and Swift. Argyrios and his team will be driving that effort. For the clang changes they will likely be first staged to swift-clang, and then discussed with the LLVM community to upstream them to mainline Clang.
  • Finally, we will be open sourcing the remaining pieces of the Swift migrator. Argyrios and his team will be handling the push back of changes there, and those changes will only be impacting the swift repository.

As usually, we’ll also be pushing back changes to have Swift work with the latest Apple SDKs. We’re expecting that push back to happen early next week. When that happens we will temporarily lock commit access to the repositories. Details about that will be sent out later in a later email. Until then, the downloadable toolchains from Swift.org will continue to work with Xcode 8.3.2. After we do the push back the downloadable toolchains will be moved to be baselined on the Xcode 9.0 betas. This shift is necessary as changes to the overlays depend on the latest SDKs.

Rick Ballard sent out an update on the Swift 4 package manager:

Hello Swift Package Manager community,

I’d like to give you an update on the state of SwiftPM in Swift 4. We’ve implemented a number of evolution proposal this Spring:

In addition to these proposals, we’ve made other significant improvements:

  • On macOS, package manifest interpretation and the package build are now sandboxed, to help mitigate the effects of maliciously crafted manifests.
  • Many error messages and diagnostics have been improved, including information about conflicts during dependency resolution.
  • Xcode project generation has been improved, and now allows schemes to reference package targets across regenerations of the project.
  • There have been a host of smaller improvements and bugfixes.

Xcode 9 lays the groundwork for first-class, native support in Xcode for Swift packages with the preview version of its new build system. This build system provides the flexibility and extensibility needed to allow Xcode to support new build models, such as Swift packages. Additionally, considerable work has gone into the SwiftPM library vended by the SwiftPM project, which will support integrating Swift packages into tools like Xcode.

So what’s left in SwiftPM 4? First, we will be implementing SE-0179, support for a swift package run command. Beyond that, we expect to start winding down this release and looking ahead to the next, though we are still open to suggestions or evolution proposals for modest features and fixes.

[…]

Other features we will likely consider for the next release cycle include support for package resources (such as image assets), license and metadata support, explicit support for handling source control forking, and a generic mechanism for invoking build tools that the package manager doesn’t natively support. Finally, we do anticipate supporting a centralized package index at some point in the future, and we may begin laying the groundwork for that in the upcoming year.

Continue reading…

Finally

And finally — self storage.