Like last week, the swift-evolution list is unusually quiet, with few responses from the Core Team. As you know, we’re in beta 6 of Xcode 8, Swift 3, and Apple’s various OSes. With August coming to an end, we should expect GM releases pretty soon. The focus right now is still on finishing up and refining this release.

Community

Matt Rajca and Alex Lorenz launched a Swift IDE that lets users program robots in Swift.

John Holdsworth has started a project to bridge Swift to Java. There are also a number of sub-projects under the SwiftJava GitHub organization. If Swift is ever to become a first-class language on Android, it will need to successfully bridge to Java as it does with C and Objective-C. This seems to be a great start! I’m sure contributions are welcome. 😊

Repositories

A number of new repositories have shown up under the Apple GitHub organization. Most relevant to this community would be the new Xcode playground support project — Logging and communication to allow Swift toolchains to communicate with Xcode.

The other new repositories are all related to the Calendar and Contacts Server project, which is a standards-compliant server implementing the CalDAV and CardDAV protocols. The project is accompanied by a number of sub-projects, all prefixed with “ccs”.

This project isn’t particularly relevant to the Swift community, although it is interesting to see more open source projects from Apple being hosted on GitHub. It was originally released in 2006 at WWDC, but I’m not sure if it had been open source before this week or not (perhaps on opensource.apple.com).

Calendar and Contacts Server repositories:

Commits and pull requests

John McCall fixed some bugs with dynamic casting: (1) fixed the cast optimizer to handle CF/NS bridging correctly, and (2) fixed the dynamic cast runtime to handle class and enum casts to AnyHashable correctly. This should unblock the fix for SR-2388.

Doug Gregor removed a ton of dead code. 🤓

Brian Gesiak added a new driver option: swiftc -continue-building-after-errors.

Brian Gesiak added another new driver option: swiftc -driver-time-compilation. This option measures the amount of time each step of the compilation process takes. Here’s an example:

$ swiftc -emit-library -module-name Crispix \
    Crispix/A.swift Crispix/B.swift Crispix/C.swift \
    -driver-time-compilation
===-------------------------------------------------------------------------===
                            Driver Time Compilation
===-------------------------------------------------------------------------===
  Total Execution Time: 0.0000 seconds (0.0875 wall clock)

   ---Wall Time---  --- Name ---
   0.0245 ( 28.0%)  link Crispix/A.swift Crispix/B.swift Crispix/C.swift
   0.0211 ( 24.1%)  compile Crispix/A.swift
   0.0209 ( 23.9%)  compile Crispix/B.swift
   0.0176 ( 20.1%)  compile Crispix/C.swift
   0.0035 (  4.0%)  swift-autolink-extract Crispix/A.swift Crispix/B.swift Crispix/C.swift
   0.0875 (100.0%)  Total

You can even add the flag to your Xcode project settings, in order to have time measurements printed to your build logs.

Maxim Moiseev & Daniel Dunbar implemented proposal SE-0137. You can find the various pull requests here: swift (1), swift (2), swift (3), swift-package-manager (1), swift-package-manager (2).

Gonzalo Larralde opened a pull request on corelibs-libdispatch with initial work for Android support.

Proposals

No new proposals! There’s nothing in review, upcoming, or waiting to be scheduled. We should take this rare opportunity to relax and take stock of Swift 3.0.

Note: there are seven proposals that were accepted for Swift 3 but were not implemented. Those will be rolling into a subsequent release. You can find them on the proposal status page.

Mailing lists

Daniel Dunbar shared an update on the status of Swift Package Manager:

The package manager was a brand new project released with open source Swift, and we have made significant progress as part of Swift 3.0. Starting from that humble beginning we now estimate there are around 3,500 Swift Packages on GitHub (*), with more and more showing up every day.

Since release, we have seen a rapid explosion in the package ecosystem with brand new Swift-based web frameworks (like Kitura, Perfect, Vapor, and Zewo), tooling and infrastructure (like the IBM Package Catalog and swiftenv), or simply adoption by existing popular Swift frameworks (like Alamofire, SnapKit, SwiftJSON, and RxSwift).

We wanted to lay out our plans for the package manager with regard to the upcoming Swift 3.0 release, some project status, and a bit about our future directions.

Release Plan

Our swift-3.0 branch was cut along with the Swift compiler project and will be our final release branch for the Swift 3.0 release. At this point, the only changes we anticipate taking onto the branch are ones that have significant impact on our current user base (primarily those focused on server-side Swift development).

Swift 3.0 will be the first official release including the package manager, which is also shipping as a command line tool inside Xcode 8. We are looking forward to seeing the ecosystem develop as these tools GM alongside the now source stable Swift 3.0!

Continue reading…

Unfortunately, it looks like SwiftPM won’t be useful for the iOS and macOS communities in the near future. Daniel Dunbar reiterates the challenges of Xcode integration mentioned last year. Rick Ballard further elaborated on this (emphasis mine):

We plan for you to be able to write iOS Swift Packages, but rather than creating a complete iOS build system in SwiftPM, this will likely work by leveraging Xcode’s build system. We think that great Xcode integration is a requirement before we will see mass SwiftPM adoption by the iOS developer community. Since Xcode is not part of the open source project, the schedule and specific plans for that work are not public – but there will be work done in the open source project to give SwiftPM a library architecture suitable for allowing it to integrate with IDEs like Xcode.

[…]

You can check this site for updates on Xcode’s open source status. 😏

Doug Gregor and Joe Groff pitched two proposal drafts, which are follow-ups to previously implemented proposals in Swift 3. Both deal with improving the bridging behavior between Swift and Objective-C — a feature that has seen frequent changes through the evolution process.

  1. Bridge Numeric Types to NSNumber and Cocoa Structs to NSValue
  2. Bridge Optional As Its Payload Or NSNull

Finally

And finally — buttons. ¯\_(ツ)_/¯