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?
Starter tasks
- 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”
Submit a task by sending a pull request or opening an issue.
Community
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.
Michael Buckley opened a pull request that implements his proposal, SE-0016: Add initializers to Int and UInt to convert from UnsafePointer and UnsafeMutablePointer. (SR-1115)
@goloveychuk merged changes to swift-package-manager to fix an issue where SPM did not support Xcode project generation for system packages. (SR-1169)
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.
Michael Ilseman merged a first draft of his proposal, SE-0044: Import as member, for the CoreGraphics APIs.
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 warn_unused_result attribute.
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.”
Deferred proposals
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.”
The
#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#selectorcompiler expression.
A proposal from Dmitri Gribenko, Dave Abrahams, and Maxim Moiseev, SE-0065: A New Model for Collections and Indices is under review.
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 writingi.successor(), one would writec.successor(of: i). We also propose the following changes as a consequence of the new model:
- A collection’s Index can be any
Comparabletype.- 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.
Mailing lists
Joe Groff pitched an idea to rename x.dynamicType to x.Self. So far, William Dillon, Eugene Gubin, and Ilya Belenkiy are enthusiastic about the idea.
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 ofSelfas a special associated type member that exists in every type for this purpose. This also happens to be what you get when ask for thedynamicTypemember of a value. We could unify these concepts and get rid of the clunkydynamicTypekeyword, replacing it withx.Self.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?)
Finally
And finally — if you work on the linker, you must be willing to relocate C++. 😅