Issue #67 27 Apr 2017
Written by: Bas Broek
A lot of proposals are being addressed this week, and Apple is working hard on an awesome Swift 4 release — and beyond. Also, it’s almost May which means we’re now just over a month away from WWDC! It will be here before you know it.
Interested in sponsoring Swift Weekly Brief? Learn more here.
Episode 8: Archival Serialization & Swift Encoders
News and community
The goal is to have a strong source compatibility test suite containing thousands of projects. We look forward to project owners helping to achieve this goal by including their open source Swift projects in the test suite.
Both proposals were only recently accepted, but would be good to get in for Swift 4. Unfortunately, the engineers on my team at Apple are fairly saturated in the near term with other tasks. If there is any interest from members of the community in taking on implementing (part of) either of these SE proposals in the near term that would be extremely welcome.
Commits and pull requests
Gelareh Taban posted minutes for the 5th Swift Server APIs Security Stream Meeting.
Joe Shajrawi opened a pull request to reduce code size:
-Ononewe have 3X binary size reduction, under
-Oa 2X binary size reduction. The text area is reduced by around 80% and 60% respectively.
Aleksey Gaponov opened a pull request to allow covariance in protocol conformance.
Thanks to Ben Cohen, you will soon be able to say
T.Element == ... instead of
T.Iterator.Element == ... in your where clauses.
Feedback from the community was positive about most aspects of the proposal. However, there was substantial disagreement about the right direction for pattern matching. The core team discussed this issue in depth.
Pattern matching is central to the use of enum types. It’s the only way you can use an enum value, besides general operations like passing it to a function or the special affordances for
Optionals. Pattern matching is as central to enums as stored property access is to structs, and it’s fair to be worried about anything that would make it substantially more onerous. Unconditionally requiring associated-value labels in case patterns would certainly do that, and several members of the core team expressed concern that it would be bad enough to discourage the use of associated-value labels completely — in effect, subverting the entire language feature being proposed.
The proposal is accepted with some revisions regarding naming:
The key/value sequence of init that does not take a closure resolving key conflicts will be named
init(uniqueKeysWithValues:). The core team felt that either possible implementation – a default way of coalescing keys, or
fatalError-ing on conflicts – could be surprising to users in ways that could easily be missed in testing. A failable initializer would probably result in frequent force-unwrapping. Giving the initializer an argument label that clearly states the uniqueness requirement fulfills the goal of making sure the caller is aware of the requirement.
The initializer that takes a sequence of pairs and a closure for conflicts will be named
init(_:uniquingKeysWith:), and the two merge methods (mutating and non-mutating) named
The group-by method on
Sequencewill be made into an initializer on
init<S: Sequence, E>(grouping elements: S, by: (E) -> Key) where Value == [E], S.Iterator.Element == E
The proposal is accepted with some minor modifications. Specifically, the core protocols and types will be sunk down into the Swift standard library for more tight integration with the Swift language and compiler, and the operations specifically involving Foundation’s
Datatype will be removed. The proposal document has been updated with more detail.
Proposals in review
As part of the introduction of the Law of Exclusivity, the current
swap(_:_:)function must be addressed, as this most common uses of
swapdirectly violate the law. This proposal introduces an alternative: a method on
MutableCollectionthat takes two indices for swapping two elements in the same collection.
Jordan Rose asked for input on how to handle renamed types when mixing and matching Swift 3 and Swift 4 code.
Should we just always import C/ObjC types under their Swift 4 names, and use typealiases in Swift 3 mode?
There are some downsides:
- We currently keep people from using Swift 4 names in Swift 3 code, and we wouldn’t be able to do that, since the actual declaration of the type always needs to be available.
- We’d probably want to tweak the “aka” printing in diagnostics to not look through these typealiases. That’s not hard, though.
- We can’t keep doing this once we have ABI stability. Hopefully framework owners aren’t going to continue changing Swift names of types, but we’ll probably need to implement my “C name in the mangling” plan anyway, just in case.
We have a proposal we’d like feedback on to revise how Swift Package Manager dependency resolution, updating, and pinning works. These changes weren’t planned in the roadmap we published a few months ago, but it’s become clear since then that we have some holes in our dependency resolution behavior that need fixing. We’ve also come to the conclusion that our original design for pinning was overcomplicated and should be revised.
Robert Widmann “decided to take a class in CoBOL to see what all the fuss is about with these modern imperative, stateful languages” 😂