Wow, it’s been quite the week! There has been a lot going on this week, and quite a few swift-evolution proposals have landed. And not the smallest ones either: what about Automatic
Hashable conformance for example? Swift 4.1 is shaping up to be a great release that will make our lives even easier. 🏎💨
Interested in sponsoring Swift Weekly Brief? Learn more here.
Episode 32: Migrating to Swift 4: JP and Jesse share their thoughts on the transition to Swift 4.
News and community
Kubra Mracek improved the display of fatal errors and wrote a blog post on Swift.org describing the changes. Now, you will see where and why a failure occurred, which is a big improvement to the previous ambiguous errors in the main function.
Commits and pull requests
Tony Allevato’s SE-0185: Synthesizing
Hashable conformance was merged! This is huge — it provides automatic
Hashable conformance for types for whose members are all
Javi Soto opened a pull request to make
+new unavailable when
-init is too.
Chris Lattner opened a pull request with some small improvements to the optimizer.
Recursive protocol constraints are now available on the master toolchain!
It was a large proposal for which most parts received a lot of support, while other parts were contentious. The proposal is accepted with revisions:
- Partial initialization/assignment will be removed from this proposal and discussed separately
- Some argument labels will be changed for clarity (
deallocate()will be removed entirely
The proposal has been accepted.
Feedback for the proposal — which many interpreted as being mostly a compiler bug fix — was limited but unanimously positive. The consensus was that removing the support for these ownership keywords in protocols removes false expectations on their behavior, which could be a source of bugs.
Jordan Rose pitched a proposal to restrict cross-module struct initializers.
While working on the non-exhaustive enums proposal I had it pointed out to me that structs actually currently leak implementation details across module boundaries, specifically their full set of stored properties. This only comes up in one place: when making an initializer for the struct in an extension in another module. We really want people to be able to change the stored properties in their structs between releases without it being a source break—that’s half the point of computed properties—and it’s also important for a struct author to be able to enforce invariants across the struct’s properties.
Chris Lattner is back to square one.