Welcome to issue #24! As noted last week, the first Swift 3 preview branch was cut and now there’s a Swift 3.0 Preview 1 milestone on GitHub tracking pull requests to be included. Currently there are 60 closed and 4 open.

Swift is about to hit another important milestone — 100 proposals. As of this writing there have been 99 Swift evolution proposals merged into the repository, many of them from the community. Swift has only been open source for about 6 months, so that’s over 16 proposals per month — nearly one proposal every other day! I’m pretty sure coordinating, reviewing, and writing swift-evolution announcement emails is Chris Lattner’s new “nights and weekends” passion. 😉

Thus, last week’s announcement about the goals of Swift 3 really should not have been a surprise. I think Dave Verwer said it best, “It’s likely that this volume of high quality community input came as a surprise to the Swift team. Certainly, if it was still closed source, the scope and features of Swift 3 would have been different.”

In other news, Apple released new betas for iOS, tvOS, and OS X.

Starter tasks

• SR-1618: [SPM] Xcode re-writes project.pbxproj for more than one module
• SR-1612: Type comparison of certain CG types with AnyObject object is always true
• SR-1453: [SPM] Improve error messages when building invalid packages
• SR-1560: [Compiler] Implement support for SE-0075, Adding a Build Configuration Import Test
• SR-1561: [Parser] implement support for SE-0081, Move where clause to end of declaration

Starter tasks are now much easier to discover in JIRA. See the Mailing List section below for details.

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

Community

Jordan Rose has written a fantastic article on his thoughts and ideas for getting into compilers and programming languages. No formal education needed! I highly recommend reading this.

Commits and pull requests

Bhaktavatsal Reddy fixed a memory leak in NSMutableData and NSData in corelibs-foundation.

Han Sangjin submitted a pull request to port corelibs-foundation to Cygwin.

Russ Bishop merged changes to remove the use of OpaquePointer in corelibs-foundation, for SE-0017.

Doug Gregor implemented proposal SE-0062, Referencing Objective-C key-paths.

Ankit Aggarwal added Objective-C support and C++ support to ClangModules for SwiftPM. He’s even written an article on how to create Objective-C and C++ packages. 🙌

Bhargav Gurlanka added support for generating framework targets in Xcode project created by SwiftPM.

Brian Croom opened a pull request to add a command line flag for printing a list of the tests in the suite in corelibs-xctest.

Joe Groff fixed an issue that prevented properly lowering types of Objective-C generic methods dispatched off AnyObject.

Janek Spaderna submitted a pull request to improve diagnostics in inheritance clauses.

Ted Kremenek fixed an issue with Dictionary and Set that would result in over-allocating the bitmap by a factor of 32 or 64, depending on the platform.

Vivian Kong has opened a pull request on corelibs-foundation to support Linux on IBM z Systems.

Joe Groff fixed crashes when conditionally looking up generic subscripts and properties via AnyObject.

Ankit Aggarwal submitted a pull request that adds a helper tool to list tests from an XCTest bundle on OSX.

Accepted proposals

Matt Wright’s proposal, SE-0088: Modernize libdispatch for Swift 3 naming conventions, was accepted with revisions for Swift 3.

The community and core team are both very positive about this massive improvement to the libdispatch APIs. Much of the discussion has centered around specific details in the proposal - for example the “.asynchronously” method on DispatchQueue. This great discussion leads to several requested revisions in the proposal:

• Rename the DispatchQueue.[a]synchronously methods to .async and .sync, to follow the term of art.
• Rename DispatchIO setHighWater, setLowWater –> setLimit(highWater:), setLimit(lowWater:)
• Rename setTargetQueue(queue:) and DispatchSource.setTimer
• Rename Semaphore, Group and WorkItem: .wait(timeout:) –> wait() and wait(withTimeout:)
• Expand source handler methods to take the same arguments as async()
• Expand DispatchQueue.after to take the same arguments as async() in addition to the when: argument

Thank you to Matt Wright proposing this, and for all of the implementation work that has gone into this so far!

Kevin Ballard’s and Erica Sadun’s proposal, SE-0094: Add sequence(initial:next:) and sequence(state:next:) to the stdlib, was reviewed and accepted with revisions for Swift 3.

• Feedback from the community & core team is positive.
• Core team discussed whether it made sense to add just the first form, or whether it made sense to add both. They agree that although the form using an explicit state is much more infrequently used, when it is necessary, it is extremely helpful to have. It is also useful to consider both as a pair.
• On naming, the core team agrees with the community that sequence(first:next:) is a better name than sequence(initial:next:). sequence(state:next:) is approved as-is.

Amended proposals

Proposal SE-0022: Referencing the Objective-C selector of a method has been amended. You can find the diff here.

Alex Hoppen, who undertook the work to implement the related proposal SE-0064, “Referencing the Objective-C selector of property getters and setters”, noted that by accepting arbitrary expressions inside a #selector expression, we made it difficult to handle the getter and setter selector cases introduced by SE-0064. It was not the original proposal’s attempt to accept arbitrary expressions, only expressions that happened to form a valid method reference, and the amendment seeks to clarify this intent.

Deferred proposals

Nate Cook’s and Sergey Bolshedvorsky’s proposal, SE-0078: Implement a rotate algorithm, equivalent to std::rotate() in C++, was deferred from Swift 3.

The general “rotate a collection by N elements” operation is a powerful operation that is nice to have in certain domains, but also has very narrow applicability. Further, the proposal has high implementation complexity (particularly when dealing with lazy collections) due to missing generics features like constrained extensions. As such, the core team has decided to defer this feature until the dependent generics features are available.

One specific exception to this deferral is the reverse() algorithm proposed for BidirectionalCollection. This algorithm is simple and straight-forward, so it is approved for Swift 3.

Joe Groff’s proposal, SE-0083: Remove bridging conversion behavior from dynamic casts, was deferred for re-evaluation later in Swift 3.

The core team and much of the community would like to get the predictability wins of this proposal. However, recent experience with the fallout of “SE-0072: Fully eliminate implicit bridging conversions from Swift” has raised some concerns that it may have overly harmed Objective-C APIs designed around the “id” type. Joe Groff will be investigating a few ideas that may help make SE-0072 work better in practice, and until they are explored and understood, the core team prefers to defer discussion on SE-0083.

Once we have clarity on the fate of SE-0072 (in the next 3-6 weeks), we can discuss SE-0083 again. Thank you to Joe Groff for this proposal, and also for helping to sort out the issues related to SE-0072.

Joe Groff’s and Tanner Nelson’s proposal, SE-0090: Remove .self and freely allow type references in expressions, was deferred from Swift 3.

The community and core team all want this proposal (or something like it) to succeed, but the core team identified several serious implementation concerns with the proposal:

• Disambiguating type vs expression cannot be done in cases where there is no contextual type available or when that type is Any. For example, in the case of let x = [Int] it isn’t clear whether this is an array value that contains the metatype for Int, or whether it is a metatype value for the type [Int]. Similar problems exist with tuple literals, including the degenerate case of let x = () which can either be the type of the empty tuple type or an empty tuple value.
• As written, the proposal has a defaulting rule that fall back to the container literal when a type literal cannot be formed. The core team prefers that the compiler treat truly ambiguous cases (where a subexpression could be considered to be either a type or a value) to be ambiguous.
• Resolving ambiguous cases requires some syntax to disambiguate between the cases, which we don’t have. This syntax should be part of the proposal.
• Having the constraint solver determine whether a subexpression is in a type or expression context is conceptually beautiful, but it introduces significant complexity into the type checker and puts more pressure onto the constraint solver. The core team would prefer to see the already planned optimizations and simplifications go into the constraint solver before this happens. This would allow us to more accurately gauge the cost of this design in practice.
• The goal of removing the Int.self syntax is a great one, but can be done at any point (beyond Swift 3) at little cost: the goal is to obsolete the T.self syntax, not to repurpose it to mean something else. This means that we can continue to accept it as deprecated syntax for a very long time with little cost to the community.

The core team would definitely like to circle back to this proposal after Swift 3 is out the door, but would recommend that such a proposal be accompanied with a prototype implementation, to validation that the chosen approach can work in practice.

Returned proposals

Austin Zheng’s proposal, SE-0089: Renaming String.init<T>(_: T), was returned for revision.

The proposal has been returned for revision and another round of discussion - the core team would love to see the revised proposal make it into Swift 3.

The community and core team both want to remove this “footgun” from the standard library, where someone could write “String(x)” with the intention of getting a value-preserving conversion to String, but may instead get a potentially lossy and potentially expensive reflection-based conversion to a String. After extensive discussion, the core team recommends that the community consider a somewhat more elaborate design…

Rejected Proposals

Proposal SE-0084: Allow trailing commas in parameter lists and tuples was rejected.

The feedback from the community was quite divided on this topic…

Swift currently accepts a trailing comma in array and dictionary collection literals, for three reasons: evolution of a project often adds and removes elements to the collection over time, these changes do not alter the type of the collection (so those changes are typically spot changes), and the closing sigil of the collection (a right square bracket) is often placed on the line following the elements of the collection. Because of these properties, accepting a trailing comma in a collection literal can help reduce spurious diffs when elements are added or removed.

That said, these properties do not translate to other comma separated lists in Swift…

Proposal SE-0087: Rename lazy to @lazy was rejected.

The community feedback on this proposal was that the most important thing was for the syntax to align with that of the forthcoming property behavior syntax. The core team does not know what that syntax will be, so it prefers to reject this proposal. […] …it would be worse to switch “lazy” to “@lazy” in Swift 3, only to switch it to something else in a subsequent release.

Proposals in review

Adrian Zubarev’s and Austin Zheng’s proposal, SE-0095: Replace protocol<P1,P2> syntax with Any<P1,P2>, is under review. Aside from the positive implications for generics, I think this is a great change to bring further consistency to the language. Repurposing the protocol keyword for composition always felt awkward and out of place to me. The community feedback on this proposal is positive so far, and Joe Groff has started some bikeshedding on an alternative form of infix syntax for composing constraints.

A stated goal for Swift 3.0 is making breaking changes to prepare the way for features to be introduced in future features, especially those involving the enhancements to the generics system detailed in Completing Generics.

One such change described in Completing Generics is renaming protocol<> to Any<> in order to allow it to serve as a syntactic foundation for more generalized existential types. This is a straightforward change which will allow a later version of Swift to introduce better handling for existential types without making breaking changes, or changes whose functionality overlaps with that of existing features.

Erica Sadun has three proposals under review this week.

• SE-0097: Normalizing naming for “negative” attributes is under review. “This proposal normalizes naming for “negative” attributes by adopting a rule that replaces property names starting with no with adjectives starting with non.” So far there’s limited and mixed feedback from the community. I’m rather neutral on this.

• SE-0098: Lowercase didSet and willSet for more consistent keyword casing is under review. There’s mixed feedback from the community on this one, mostly leaning against the change. It seems like Joe Groff’s concern over potential language churn has shifted opinions: “didSet and willSet are already contextual rather than formal keywords, and there’s a conceivable future where didSet and willSet are no longer keywords at all if we run with the ‘property behaviors’ feature again in the future. If we think that’s likely, I’m not sure this intermediate churn is really worth it.”

• SE-0096: Converting dynamicType from a property to an operator is under review. There’s positive support for this change from the community.

In Swift, dynamicType is a property. Because of that, it shows up as an “appropriate” code completion for all values regardless of whether it makes sense to do so or not. For example, Swift offers 4.dynamicType and myFunction().dynamicType, etc. Unlike most properties, it does not express a logical attribute of a specific type. Instead, it can be applied to any expression. Since dynamicType behaves more like a operator (like sizeof), its user-facing calling syntax should follow suit.

Mailing lists

Brian Gesiak shared the new swift-corelibs-xctest JIRA dashboard that he created. 🙇

If you’re like me, you might be curious how Core Libraries like swift-corelibs-xctest are doing with regards to the looming Swift 3.0 release. Well, wonder no more… […] The dashboard not only lists tasks that need to be resolved by Swift 3.0, but also open starter tasks for new contributors.

Following Brian’s lead, Daniel Dunbar announced a dashboard for SwiftPM. Brian also created a dashboard for corelibs-foundation and Philippe Hausler added a bunch of starter tasks. Each of these dashboards make it super easy to manage tasks and discover starter tasks. 👏

Finally

And finally — “Yes, it’s true: with a little tuning, C can be just as fast as Swift.” 😂 (Great article from Matt Gallagher this week.)