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.

Starter tasks

SE-0168 has been implemented, but you can still help out improving diagnostics and adding fixits to improve the usage for yourself and others.

Submit a task by sending a pull request or opening an issue.

Swift Unwrapped

Episode 8: Archival Serialization & Swift Encoders

This week, JP Simard and Jesse Squires take a closer look at SE-0166 and SE-0167 which seek to improve serialization and encoding in Swift.

News and community

Apple announced a test suite for Swift source compatibility, where you can add your open source project to the test suite. A regression has already been found (and has been fixed)! 😱

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.

Ted Kremenek asked for help implementing SE-0155 and SE-0169. Get involved!

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:

Under -Onone we have 3X binary size reduction, under -O a 2X binary size reduction. The text area is reduced by around 80% and 60% respectively.

John Holdsworth, who co-authored SE-0168: Multi-Line String Literals has already implemented the proposal. 🎉

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.

Accepted proposals

SE-0155: Normalize Enum Case Representation was accepted with revisions.

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.

Continue reading…

SE-0165: Dictionary & Set Enhancements was accepted with revisions.

The proposal is accepted with some revisions regarding naming:

  1. 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.

  2. 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 merge(_:uniquingKeysWith:) and merging(_:uniquingKeysWith:).

  3. The group-by method on Sequence will be made into an initializer on Dictionary: init<S: Sequence, E>(grouping elements: S, by: (E) -> Key) where Value == [E], S.Iterator.Element == E

SE-0166: Swift Archival & Serialization was accepted with revisions.

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 Data type will be removed. The proposal document has been updated with more detail.

SE-0167: Swift Encoders was accepted.

SE-0171: Reduce with inout was accepted for Swift 4.

SE-0172: One-sided Ranges was accepted for Swift 4.

Proposals in review

SE-0173: Add MutableCollection.swap(_:with:) by Ben Cohen is under review.

As part of the introduction of the Law of Exclusivity, the current swap(_:_:) function must be addressed, as this most common uses of swap directly violate the law. This proposal introduces an alternative: a method on MutableCollection that takes two indices for swapping two elements in the same collection.

Mailing lists

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.

Rick Ballard pitched a proposal to improve the Swift Package Manager’s dependency resolution… coincidentally after listening to the Swift Unwrapped podcast on this topic!

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.

Finally

Robert Widmann “decided to take a class in CoBOL to see what all the fuss is about with these modern imperative, stateful languages” 😂