Welcome to issue 23! This week Apple released iOS 9.3.2 and OS X 10.11.5. We’re only one month away from WWDC, and Realm just announced that they will be hosting another WWDC Swift Panel this year, if you’ll be here for the conference you should RSVP! It would be great to see you there. 😄
Chris Lattner also announced updates on the goals and status of Swift 3. See the details below in the Mailing lists section.
Starter tasks
- SR-1554: [Parser]
//*/does not close multi-line comment - 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
whereclause to end of declaration
From Brian Gesiak:
- SR-1165: Swift currently translates both
-[XCTest run]and-[XCTestRun runTest]asXCTest.run(). Modify the apinotes for Apple XCTest such that Swift does not generate duplicate signatures for these two methods. This task will introduce you to Swift’s “apinotes” feature, as well as with building the Swift project and running its test suite. Prerequisite: basic knowledge of Swift syntax.
Submit a task by sending a pull request or opening an issue.
Commits and pull requests
Bryan Chan from IBM submitted a number of pull requests this week to support Linux on IBM z systems. You can find the various pull requests here: swift, swift-clang, swift-llvm (1), swift-llvm (2), swift-lldb.
Russ Bishop implemented proposal SE-0032, adding a first(where:) method to Sequence.
Ingmar Stein submitted a pull request that fixes an issue where C preprocessor macros with casts are not visible to Swift.
Brian Gesiak continued work on SR-710, which is tracking generating XCTestCaseProvider entries on Linux.
Russ Bishop opened a pull request that implements SE-0017, changing Unmanaged to use UnsafePointer.
@JPMartha submitted a pull request to improve the --fetch behavior in Swift Package Manager. Looks like a big step forward for improving dependency resolution.
Joe Groff fixed an issue where subclasses did not inherit protocol conformance from superclasses (SR-1480).
Nicola Salmoria opened a pull request to add non-optional overloads of XCTAssertEqual and XCTAssertNotEqual.
Dan Liew submitted a pull request to “teach the Swift front-end to generate code with ‘Sanitizer Coverage’ with a new command line flag -sanitize-coverage=. This flag is analogous to Clang’s -fsanitize-coverage=.”
David Farler and Slava Pestov have been working on an out-of-process reflection infrastructure. From Joe Groff: “Debuggers and memory tools can now look at a Swift binary or running process and explore its object graph.”
Accepted proposals
David Hart’s and Doug Gregor’s proposal, SE-0092: Typealiases in protocols and protocol extensions, was accepted. The proposal was proactively approved by the core team without a formal review period because of its obviousness, and to optimize the process. Greg Titus has already started the implementation work on this.
The core team consider this as an obvious follow-on to SE-0011. […] If there are any serious concerns, please raise them and we are happy to reconsider and start a normal review cycle.
Erica Sadun’s proposal, SE-0075: Adding a Build Configuration Import Test, was accepted.
The community and core team are both very positive about adding this functionality. It is precedented by the
__has_includefeature in Clang, and may have applicability allowing “conditionally available” features for SwiftPM modules in the future. The core team spent a significant amount of time discussing the proper naming for this, and came to agree that “canImport” (as proposed) is the best name for this conditional.
The proposal from David Hart, Robert Widmann, and Pyry Jahkola, SE-0081: Move where clause to end of declaration, was accepted.
The feedback on this proposal was strongly positive from the community and core team. Some concerns were raised (e.g. about possible interaction with the future “generalized existentials” feature) but further examination turned up that they were at issue regardless of whether this feature is accepted. The core team agrees that this syntactic structure allows a more natural and beautiful way to structure complex generic constraints, and that “where” clauses should be considered secondary to the primary signature of the declaration (e.g.
func,class, etc) in question.
Amended proposals
An amendment for proposal SE-0039: Modernizing Playground Literals was reviewed. The pull request with the changes is here, and it looks like Erica Sadun has approved.
The Swift core team would like to amend this proposal to spell out what’s happening with the literal protocols. The proposal was not explicit about the fact that the protocols were going to change, and in fact it turned out that changing them was not a good idea. We’ve already applied the effects of this amendment in trunk, but that is a decision that should be ratified by the community. Please do not allow the fact that it’s “already done” to discourage you from speaking up if you have strong feelings about this amendment. […] We view this as a minor amendment to the proposal.
Rejected proposals
Proposal SE-0041: Updating Protocol Naming Conventions for Conversions was rejected.
The feedback on the proposal was generally positive about the idea of renaming these protocols, but the specific names in the proposal are not well received, and there is no apparent confluence in the community on better names. The core team prefers discussion to continue — if/when there is a strong proposal for a better naming approach, we can reconsider renaming these.
Proposals in review
Erica Sadun’s and Xiaodi Wu’s proposal, SE-0050: Decoupling Floating Point Strides from Generic Implementations, is under review.
Swift strides create progressions along “notionally continuous one-dimensional values” using a series of offset values. This proposal supplements Swift’s generic stride implementation with separate algorithms for floating point strides that avoid error accumulation.
Anton Zhilin’s proposal, SE-0077: Improved operator declarations, is under under review.
In the beginning, operators had nice precedence values: 90, 100, 110, 120, 130, 140, 150, 160.
As time went, new and new operators were introduced. Precedence could not be simply changed, as this would be a breaking change. Ranges got precedence 135,
asgot precedence 132.??had precedence greater than<, but less thanas, so it had to be given precedence 131.Now it is not possible to insert any custom operator between
<and??. It is an inevitable consequence of current design: it will be impossible to insert an operator between two existing ones at some point.
Anton Zhilin’s proposal, SE-0087: Rename lazy to @lazy, is under review. This proposal aims to make lazy a modifier attribute instead of a keyword.
Austin Zheng’s proposal, SE-0089: Renaming String.init<T>(_: T), is under review.
Swift’s
Stringtype ships with a large number of initializers that take one unlabeled argument. One of these initializers, defined asinit<T>(_: T), is used to create a string containing the textual representation of an object. It is very easy to write code which accidentally invokes this initializer by accident, when one of the other synonymous initializers was desired. Such code will compile without warnings and can be very difficult to detect.
Joe Groff’s and Tanner Nelson’s proposal, SE-0090: Remove .self and freely allow type references in expressions, is under review.
Swift’s grammar currently requires that type references only appear as part of a constructor call
T(x)or member accessT.x. To get the metatype object forT, one must refer to the special memberT.self. I propose allowing type references to appear freely in expressions and removing the.selfmember from the language.
Tony Allevato’s proposal, SE-0091: Improving operator requirements in protocols, is under review.
When a type conforms to a protocol that declares an operator as a requirement, that operator must be implemented as a global function defined outside of the conforming type. This can lead both to user confusion and to poor type checker performance since the global namespace is overcrowded with a large number of operator overloads. This proposal mitigates both of those issues by proposing that operators in protocols be declared statically (to change and clarify where the conforming type implements it) and use generic global trampoline operators (to reduce the global overload set that the type checker must search).
Mailing lists
Chris Lattner announced updates regarding the goals of Swift 3. Unfortunately, it looks like a major goal for Swift 3 — ABI stability — will not be completed. This means developers will have to keep bundling the Swift runtime with their apps and all Swift binaries will need to be re-compiled for future versions of Swift. The goal to complete generics was also missed. The good news, however, is that Swift 3 has made source stability a priority, meaning source-breaking changes should be minimal moving forward. Chris has updated the main README in the swift-evolution repository to reflect these changes. You can see the diff of changes here.
This release is shaping up to be a really phenomenal release that will redefine the feel of Swift and make a major leap towards maturing the Swift language and development experience. We have had a focus on getting to source stability, with the forward-looking goal of making Swift 4 as source compatible with Swift 3 as we can reasonably accomplish. It tackled API naming head on (which is one of the hardest problems in computer science [1]), made major improvements to the consistency and feel of the language, and has several nice across the board additions.
That said, it is also clear at this point that some of the loftier goals that we started out with aren’t going to fit into the release - including some of the most important generics features needed in order to lock down the ABI of the standard library. As such, the generics and ABI stability goals will roll into a future release of Swift, where I expect them to be the highest priority features to get done.
[…]
[1] It is well known that the two hard problems in Computer Science are naming, cache invalidation, and off-by-one errors.
Regarding the ABI, Greg Parker shared some fascinating insights on the history of Objective-C. I definitely recommend reading the full email.
We apologize for the inconvenience.
The OS X and iOS architecture transitions demonstrate the two fundamental laws of ABI changes:
- Opportunities to break ABI compatibility are rare.
- Any opportunity to break ABI compatibility will suffer from severe schedule pressure.
The Objective-C ABIs have many problems that would have been improved with more time. […]
If we tried to rush Swift ABI stability out the door for Swift 3 we would certainly end up with deliberate or accidental flaws like the above. Being able to take the time to get it right is a rare luxury.
Austin Zheng started a discussion about a proposal to enhance existential types. He’s prepared a great skeleton proposal and is looking for feedback from the community. “Be unsparing; whatever form this feature takes will profoundly affect how Swift developers program for years, so it needs to be done right.”
Austin Zheng also pitched an idea on renaming protocol<> to Any<> for Swift 3 and drafted a proposal.
Finally
And finally — Swift 3 preview 1 has branched. 😂 (Some background here.)