If you have not heard it already, the big news this week is that the port to Android pull request from Brian Gesiak and Zhuowei Zhang has finally merged after a month and a half of review and discussion. 🎉 👏 🙌 No matter what, this was going to be significant addition to Swift. However, as Dave Verwer noted in iOS Dev Weekly last week, it seems even more important given the recent rumors that Google may be considering Swift for Android.
As mentioned last week, the Swift 2.2.x milestone is still open and remains unchanged — all 33 issues closed. The Swift 2.2 branch is currently 363 commits ahead of master, but the most recent activity was 8 days ago. Maybe we’ll see an official release soon?
- SR-1187: [SPM] Add example test to Dealer example
- SR-1174: [llbuild] Properly escape verbose command descriptions
- SR-580: [Compiler] Warning should be produced for “variable was never mutated”
In other exciting news, @NatashaTheRobot is organizing another try! Swift conference. This time it will be in NYC. The first one was great, so I highly recommend attending if you can. The current list of speakers looks great! 🤓
I just noticed this week that Nate Cook has updated swiftdoc.org to include not only the latest Swift 2.2 docs, but multiple other versions of the stdlib — including Swift 3.0 from swift/master and the new index model. This is such a great resource! 🙇 The entire site and other tools are on GitHub if you want to contribute. I also noticed the updated copyright footer on the site, “All content copyright © 2014–2016 Apple Inc. All rights reserved.” 😧
Commits and pull requests
Harlan Haskins opened a pull request that adds a fixit to hide the first parameter label in functions. This is part of the effort to implement SE-0046: Establish consistent label behavior across all parameters including first labels.
Daniel Duan merged some changes to clean up SILGen, eliminating SILGen for
var parameters in functions, which are being removed in Swift 3.
Manav Gabhawala opened a pull request that fixes an infinite recursion in the compiler when inheriting from a member of the same type.
Joe Groff merged changes that allow subclasses of specific instantiations of Objective-C generic classes.
Brian Gesiak merged changes that unify the Linux and FreeBSD modulemaps with gyb to reduce code duplication.
Daniel Cohen Gindi opened and later closed a pull request to allow
Strideable to have a zero size. “But moreover, Xcode itself expects it to allow 0 length stride. As Xcode automatically converts old for-loops to strides, it actually breaks code that may in some cases have zero-length strides.” This is definitely something to watch out for if you are migrating to Swift 2.2 with Xcode’s migration tool. As noted on the pull request, this particular patch was not the right one, but it has convinced Dave Abrahams that there needs to be a
stride function that works for this case.
Trent Nadeau merged changes for part of SR-1052, which is tracking the implementation of SE-0047: Defaulting non-Void functions so they warn on unused results. His patch adds the
@discardableResult attribute to imported C declarations without the Clang
Manav Gabhawala opened a pull request that fixes the
IterativeTypeChecker and better manages circular protocol inheritance. “Improves the diagnostics produced for circular protocol inheritance, further it improves the IterativeTypeChecker to use loops instead of recursion to help minimize the stack size and lastly improves the efficiency of detecting circular inheritance by making it a part of the main cycle when checking for inherited protocols.”
Russ Bishop’s and Doug Gregor’s proposal, SE-0058: Allow Swift types to provide custom Objective-C representations has been deferred from Swift 3. Joe Groff explains that it is simply too early to commit to a public API for this. Interestingly, he mentions the idea of bridging with JVM in the future… 🤔 🤐
We agree that it would be valuable to give library authors the ability to bridge their own types from Objective-C into Swift using the same mechanisms as Foundation. However, we lack the confidence and implementation experience to commit to
_ObjectiveCBridgeablein its current form as public API. In its current form, as its name suggests, the protocol was designed to accommodate the specific needs of bridging Objective-C object types to Swift value types. In the future, we may want to bridge with other platforms, including C++ value types or other object systems such as COM, GObject, JVM, or CLR. It isn’t clear at this point whether these would be served by a generalization of the existing mechanism, or by bespoke bridging protocols tailored to each case. This is a valuable area to explore, but we feel that it is too early at this point to accept our current design as public API.
Proposals in review
David Hart’s proposal, SE-0062: Referencing Objective-C key-paths, is under review. “In Objective-C and Swift, key-paths used by KVC and KVO are represented as string literals. This proposal seeks to improve the safety and resilience to modification of code using key-paths by introducing a compiler-checked expression.” David proposes adding a new
#keyPath expression, similar to newly added
#selector expression in Swift 2.2. It seems like a reasonable follow up on Doug Gregor’s SE-0022. Surprisingly, there is not much feedback on the lists yet, but it is positive.
David Hart’s proposal, SE-0064: Referencing the Objective-C selector of property getters and setters, is under review. This proposal is a great extension of Doug Gregor’s SE-0022, that will address its current deficiencies. Again, there is not much feedback for this proposal either, but the feedback so far is positive.
“Proposal SE-0022 was accepted and implemented to provide a #selector expression to reference Objective-C method selectors. Unfortunately, it does not allow referencing the getter and setter methods of properties. This proposal seeks to provide a design to reference those methods for the Swift 3.0 timeframe.”
#selectorexpression is very useful but does not yet cover all cases. Accessing property getter and setters requires to drop down to the string syntax and forgo type-safety. This proposal supports this special case without introducing new syntax, but by introducing new overloads to the
We propose a new model for
Collections wherein responsibility for index traversal is moved from the index to the collection itself. For example, instead of writing
i.successor(), one would write
c.successor(of: i). We also propose the following changes as a consequence of the new model:
- A collection’s Index can be any
- The distinction between intervals and ranges disappears, leaving only ranges.
- A closed range that includes the maximal value of its
Boundtype is now representable and does not trap.
- Existing “private” in-place index traversal methods are now available publicly.
As expected with such a fundamental change, there’s a lot of discussion. Nate Cook expresses some concern over APIs and naming, but ultimately gives it a +1000. There are a number of other +1’s on the lists, too. I think the community is in favor of the core idea, it’s just a matter of working out some of the details, and Brent Royal-Gordon is doing just that.
It’s been pitched before, but I don’t think we’ve had a dedicated thread to this idea. Erica has proposed making
Selfgenerally available within methods in types to refer to the dynamic type of the current receiver. One could think of
Selfas a special associated type member that exists in every type for this purpose. This also happens to be what you get when ask for the
dynamicTypemember of a value. We could unify these concepts and get rid of the clunky
dynamicTypekeyword, replacing it with
There’s another benefit to this syntax change. Looking to the future, one of the many features Doug pitched in his generics manifesto was to generalize protocol existentials, lifting our current restrictions on protocols “with Self or associated types” and allowing them to be used as dynamic types in addition to static generic constraints. Once you do this, you often want to “open” the type of the existential, so that you can refer to its Self and associated types in the types of other values. I think a natural way would be to let you directly use Self and associated type members of existentials as types themselves
Jacob Bandes-Storch started a discussion on adding arbitrary requirements in protocols, noting what Doug Gregor wrote in the Completing Generics manifesto. He asks what it would take to get this feature into Swift 3.
Along with the discussion over the SE-0065 proposal, Joe Groff, Stephen Canon, Trent Nadeau, and Dave Abrahams, discuss the grammatical merits of “indices” versus “indexes”. 😂 I guess sometimes grammar is context-sensitive. 😉 (See what I did there?)
And finally — if you work on the linker, you must be willing to relocate C++. 😅