Welcome to issue #11 of the weekly brief! There was big news this week with IBM’s announcement on bringing Swift to the cloud with a new open web framework called Kitura and the IBM Swift Package Catalog. The test framework for Kitura server is even using corelibs-xctest. 😎 Apple’s partnership with IBM is definitely starting to benefit the community! 🎉

Xcode

Apple released Xcode 7.3 beta 4 this week with significant changes! The following proposals are included in the release:

  • SE-0020: Swift Language Version Build Configuration, by David Farler
  • SE-0022: Referencing the Objective-C selector of a method, by Doug Gregor
  • SE-0011: Replace typealias keyword with associatedtype for associated type declarations, by Loïc Lecrenier
  • SE-0021: Naming Functions with Argument Labels, by Doug Gregor
  • SE-0028: Modernizing Swift’s Debugging Identifiers, by Erica Sadun

Commits and pull requests

Joe Groff merged his property behaviors prototype into master. (Note that the pull request was closed.) It is currently hidden behind a frontend flag, -enable-experimental-property-behaviors. Joe also worked on handling initial value requirements in property behaviors. “This lets us implement lazy as a property behavior.” 🎉

Joshua Garnham fixed a bug in the parser where a fix-it would suggest moving an @noescape attribute declaration to the function attribute position, rather than the parameter. (SR-215)

Greg Titus opened a pull request to support multiple patterns in switch cases that contain variables. “There was a thread on swift-evolution back on Jan 23rd about adding this, and the response from the team was that it was something desirable but that you just hadn’t had time to do it so far.” 😎 This change will enable things like this:

enum Foo {
  case A(String, Int)
  case B(Int, String, String)
  case C(Int)
}

func thingy(arg: Foo) -> String {
  var r: String
  switch(arg) {
  case .A(let s, let i), .B(let i, _, let s):
    r = "\(s)\(i)"
  case .C:
    r = "c"
  }
  return r
}

Brian Gesiak documented the swift-compiler tool in swift-llbuild. 🙇

Mishal Shah added a pull request template to support GitHub’s new feature.

Eric Holscher setup Swift 2.2 documentation on ReadTheDocs.org, and added a link in the README. Now you don’t have to build it yourself. 👏 I feel like this was the purpose of the Swift Internals site, yet it still has not been updated to include these. 🤔

@codestergit implemented NSCountedSet in corelibs-foundation.

The previously mentioned port to cygwin has now been merged!

Proposals

A number of proposals have been rejected this week. Personally, I think the rationales for each rejection are very reasonable and practical. I think it’s important to note a few things here. Rejections are not negative. Each time we finish a swift-evolution review — regardless of the outcome — it means we are that much closer to shaping and refining our language. Thus, if your proposal gets rejected, you should not feel discouraged — nor should you stop participating! Finally, don’t shoot the messenger! 😄

Proposal SE-0024, Optional Value Setter ??=, was rejected. In short, “…the use cases are not strong enough to motivate inclusion of this operator.”

Proposal SE-0027, Expose code unit initializers on String, was rejected. “The core team feels that we have not fully explored the design space here. […] The String type itself is undergoing a significant re-evaluation, so the core team feels that improvements to String should be delayed until the newer design is better understood.”

Proposal SE-0010, Add StaticString.UnicodeScalarView, was rejected. “The core team felt that it would be inconsistent just to add this narrow set of APIs for Unicode scalars. […] If StaticString is to gain Unicode support, it should be done comprehensively, not piecemeal. Moreover, with the aforementioned String re-evaluation underway, it is possible that StaticString itself might change considerably or even be obsoleted.”

Proposal SE-0030, Property Behaviors, was rejected in its current form and now has a status of under revision. “The core team believes that property behaviors are a worthwhile feature for Swift, but it’s clear from the discussion that we as a community have not yet converged on a design we are willing to commit to. It is therefore too early to accept a proposal for this feature.” While it may be disappointing that this proposal is not quite ready, it is great to know that the core team is really listening to and collaborating with the community. 😊

Proposal SE-0035, Limiting inout capture to @noescape contexts by Joe Groff, has been accepted! “This proposal has been very positively accepted by the community at large as well as the core team, and folks widely agree that it eliminates a common source of surprise, making Swift more predictable.” Work for this is being tracked at SR-807.

Proposal SE-0033, Import Objective-C Constants as Swift Types by Jeff Kelley, is now under review. Overall, support for this on the mailing lists was positive.

Mailing lists

The mailing lists went down for a couple of hours on Monday (Feb. 22). Be sure to resend any messages that might have gotten lost.

Max Howell started threads (swift-build-dev, swift-evolution) to announce plans for Xcode integration with the Swift Package Manager. 🎉 This work is going to happen on GitHub, and begin presently.

One of our goals for the Swift Package Manager is excellent and delightful integration with Xcode. To this end we are going to start work on initial integration by making SwiftPM able to generate Xcode project files. This is not the long-term design we want for the Xcode integration, but it is a concrete step we can take now which will allow Xcode users to adopt Swift packages and use them in their products. […] We would like to emphasize again that proper and tight integration with Xcode is our long-term goal, but in the near-term we consider this a good intermediary solution — making real Swift package use possible.

Our design for this feature is as follows:

  • Generate a single xcodeproj from the command line for a Package.swift
  • The xcodeproj will contain targets for all packages and their modules
  • Require the user to add this xcodeproj to their main project and link the dependency by hand.

[…] We are aware of the frustrating aspects of other systems that generate Xcode projects and will be looking at ways to mitigate the problems that come with this solution.

Kevin Ballard shared an idea for adding #if os(Darwin) as shorthand for any Apple platform. There’s mostly support for this, but more importantly it has raised other considerations, such as how to handle different Linux distros. At the very least, it has been acknowledged that current state of #if os(...) is lacking.

Joe Groff pitched an idea on flattening the function type of unapplied instance methods. It’s a bit dense and difficult to summarize, so I’ll just refer you to his initial message. 😁

Finally

And finally — the headline writes itself. “Three Decades Later, Apple Flipping a New Bird at IBM”. 😂