It has been a week since WWDC; have you had a chance to see what your Swift 4 upgrade path looks like yet? Mine started with an increase in redundant protocol conformance warnings, and I found one minor regression. That said, it has been pretty smooth so far, especially compared to the two weeks I spent on the Swift 3 upgrade last year!
Also, keep in mind that Swift 3.2 is the Swift 4 compiler running in Swift 3 compatibility mode (-swift-version 3, which clicked for me sometime during WWDC 😅). Understanding this can be really helpful when putting together a ticket for bugs.swift.org.
有兴趣赞助 Swift Weekly Brief？点击这里
Starter tasks
- SR-4866: Stack overflow: Parsing phony empty paren expressions
- SR-4830: Propagate colors from compiler output
Submit a task by sending a pull request or opening an issue.
Swift Unwrapped
Episode 15: What’s New in Swift 4, Part 2
JP Simard and Jesse Squires continue their discussion on what to expect with Swift 4.
News and community
John Sundell wrote about the new Swift 4 String APIs. The post includes lots of useful examples that show where you might start using them in your day-to-day Swift.
Slava Pestov proposed a Swift puzzle on Twitter: What does this output and why? print(type { }) (answer here)
Slava also highlighted that the Swift compiler team has fixed more than 5,500 crashers since this commit in 2014. 🎉
Commits and pull requests
Slava Pestov fixed a bug in Swift 4 and 3.1 related to superclass initializer delegation where Swift might incorrectly reject a self.init call as an escaping use of self for certain kinds of superclass initializers.
Devin Coughlin continued work on Swift 4 memory exclusivity by adding analysis for inout params.
Nate Cook made lots of documentation revisions for the Swift 4 stdlib.
Dave Abrahams opened a PR with some performance optimizations for String.
Roman Levenstein cherry-picked a patch from master to the Swift 4 branch that reduces the standard library code size by about 5-6 percent.
Proposals
No updates on proposals this week! Check the status page for details.
Mailing lists
There is some discussion about the role of the Swift Evolution mailing lists as it relates to promoting useful discussion and review of proposals and, given how this is guided by the Swift release cycle/stages, how one should bring up ideas for serious discussion that may not be “in-scope” for current release stage.
Ted Kremenek writes:
Everyone: this is a great thread, and I appreciate the candid thoughts here. This is something Ben Cohen and I started chatting about offline and we’ll definitely bring it up for discussion with the rest of the Core Team.
[…]
Getting to Xiaodi’s observation, the evolution list is really the most effective as a working list for bringing forward in-scope proposals. There’s a ton of different topics people want to talk about — and their is some obvious angst about getting to those — but at the end of the day there is only so much bandwidth from everyone to pay attention to these discussions and to get seriously invested in them. Maybe moving to Discourse (which is something we still want to do, but have had limited bandwidth to implement) will provide the “off-list” communication channels analogous to the ones Xiaodi describes that keeps those discussions in the Swift.org discussion forums but clearly separates discussion for in-scope proposals versus the side discussions people want to have on topics they are interested in.
[…]
If you’re interested in the future of Swift Evolution, this is a worthwhile read about how the process has served to promote useful discussion around “in-scope” ideas and how it needs improvement when it comes to discussing ideas that may not fit into the current Swift release stage.
Chris Lattner responded to an ongoing thread about revisiting SE-0110:
We discussed this in the core team meeting today. Consensus seems to be that a change needs to be made to regain syntactic convenience here. Discussion was leaning towards allowing (at least) the parenthesized form, but more discussion is needed.
One (tangential) thing that came up is that tuple element names in tuple patterns should probably be deprecated and removed at some point. Without looking, what variables does this declare?:
let (a : Int, b : Float) = foo()?
We covered this back in issue #72. In Swift 4, N-ary tuples are no longer expanded to N arguments in a closure (the “tuple splat behavior”). This means closures will receive a single tuple parameter and you’ll have to expand them manually. This has (obviously) proved to be much less ergonomic and poorer developer experience. It’s nice to see the Core Team reconsider this change! And who said swift-evolution wasn’t great? 😉
Finally
A few words for Swift 2 🍺.