Issue #50 15 Dec 2016
Written by: Jesse Squires
Welcome to the 50th issue of the weekly! It’s hard to believe we’ve reached this milestone! 😊
This week Ted Kremenek wrote an official post on the 3.1 release process. Swift 3.1 is intended to be source compatible with Swift 3.0 and set for release in Spring 2017. (Spring for those of us in the Northern Hemisphere. 😉) The final date to accept major changes for Swift 3.1 will be around January 16, 2017. As Chris Lattner noted: “Swift 3.1 is the first release to benefit from the new era of source compatibility, a result of swift-evolution refining and polishing 3.0!”
This will be the last issue for 2016. But don’t worry, I’ll still be periodically tweeting anything interesting. Swift.org will likely start to quiet down over the coming weeks. If you’re in the US, enjoy the holidays and (hopefully) time off. We’ll be back in January!
News and community
The final version of Xcode 8.2 was released, along with updates for all of Apple’s platforms. (Release notes)
Soroush Khanlou wrote a post on Guarding Against Long Compiles. It turns out that it’s pretty easy to have Xcode generate warnings for functions that take too long to type-check.
The video for Mike Ash’s talk Exploring Swift Memory Layout at GOTO Copenhagen 2016 is now online. As always, Mike does a great job explaining complex topics.
There were some interesting discussions on Twitter this week, so how about a new section in the weekly? 😄
Rob Napier started a thread on the semantics of nil versus the empty string ("") when dealing with String?.
Nick Lockwood asked, What’s the collective term for constants and variables in Swift? “properties”? ¯\_(ツ)_/¯
Ole Begemann investigated how Swift 3 handles the new emoji in iOS 10.2. Spoiler: it isn’t Unicode 9.0 compliant yet. ☹️
Commits and pull requests
Slava Pestov (@slava_pestov) found and fixed a ‘horrific’ Swift 3 compatibility bug. When they say Swift 3.1 will be compatible with Swift 3, they’re serious. 😅
Hugh Bellamy (@hughbe) continued working on the port to Windows with a number of pull requests:
- Port swift-lldb to Windows, #105
- Support building swift/AST with MSVC on Windows, #5948
- Port stdlib/public/stubs/GlobalObjects to Windows, #6239
- Fix errors and warnings building swift/SIL on Windows using MSVC, #5954
Erik Eckstein (@eeckstein) fixed an issue where the compiler would seg fault with -O and -whole-module-optimization.
Chris Bailey (@Chris__Bailey) posted the meeting minutes from the Server APIs work-group HTTP stream meeting.
Karl Weinmeister (@kweinmeister) opened a pull request on corelibs-foundation to finish implementing NSLengthFormatter.
Michael Ilseman, the Swift compiler dog, (@Ilseman) cleaned up the clang importer in preparation for dealing with Swift source compatibility.
Doug Gregor (@dgregor79) fixed a constraint solver issue where after binding a type variable, not all affected constraints would be activated.
Proposals
No updates this week! Check the status page to see the current state of proposals.
Mailing lists
Brian King started a thread on changing NSObject dispatch behavior.
I wanted to follow up to a blog post I wrote about Message Dispatch in Swift. I mentioned some changes to NSObject that didn’t result in any objections, so I thought it was time to see what the SE mailing list thought.
I’ve read a few conversations on SE mailing list that have morphed into abstract conversations about dynamic vs static dispatch. I want to focus specifically on how Swift NSObject subclasses behave.
I think that there are 2 changes that will result in fewer bugs and will not have a substantial impact on performance:
Finally
And finally — “What is a software engineer’s job?” #yatusabes