I am back! I had the most wonderful time at WWDC, learning a lot of and meeting awesome people. I want to specifically thank all those that have shown their gratitude for the weekly brief, it’s much appreciated!

Without further ado, here’s this week’s news on the Swift.org open source projects.

Starter tasks

  • SR-7984 [Compiler] Constraint to concrete type using : should offer a fixit
  • SR-8012 [Standard Library] Remove Indexable aliases
  • SR-8049 [Swift for TensorFlow] Open source S4TF unit testing with a remote TF session

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

Swift Unwrapped

In episode 63, Jesse and JP discuss Swift algorithms and data structures with Kelvin Lau and Vincent Ngo.

In episode 64, Jesse and JP discuss Never, the return type of functions that do not return normally.

News and community

Ole Begemann wrote a blog post with thoughts on @dynamicMemberLookup, which was introduced in SE-0195.

John Sundell discussed the Swift Package Manager with David Hart in his podcast.

Commits and pull requests

Slava Pestov merged a pull request to fix a corner case for source compatibility. As it appears, using an enum case called init could cause some trouble.

Ankit Aggarwal merged a pull request that adds a new, SwiftPM specific proposal template that better reflects the expectations and nuances of this project.

Accepted proposals

SE-0211: Add Unicode Properties to Unicode.Scalar has been accepted with revisions.

The core team has accepted this proposal, with one revision:

  • the numericValue property should be a Double? rather than a Double, with nil for non-numeric values rather than NaN.

SE-0214: Renaming the DictionaryLiteral type to KeyValuePairs has been accepted with revisions.

In the review thread discussion, many names were considered, and the core team agreed that KeyValuePairs (initially KeyValueList was proposed) is a best name suggested on the thread for this type.

Swift Forums

Ankit Aggarwal shared some features and enhancements that have been brought to SwiftPM recently.

  • Improved scheme generation logic
  • Local dependencies
  • Automatic Xcode project generation
  • System library targets
  • Embeddable Xcode projects

Dave DeLong and Erica Sadun pitched a proposal to introduce namespacing for common Swift error scenarios.

This proposal introduces namespacing for fatal errors. It provides an umbrella for common exit scenarios, modernizing a holdover from C-like languages.

Swift’s fatalError is arguably insufficient for a multitude of real world uses including discoverability, extensibility, and significance. Swift lacks a modern extensible solution that differentiates fatal error scenarios.

Awesome stuff!

Steve Canon pitched a proposal that aims to solve some issues around floating points and their min and max operations.

There is a small but important tangle of issues around the interaction between min and max operations and Comparable and FloatingPoint protocols and the IEEE 754 standard that I would like to attempt to resolve.

Ankit Aggarwal shared a list of SwiftPM evolution ideas that could use some help to get proposals off the ground.

This is a list of some evolution ideas for the package manager. Once the details of an idea are fleshed out and there is a full proposal, it can be scheduled for the swift-evolution process. It is important to note that not every idea on this list is guaranteed to become an official feature, and it all depends on where the design discussion leads us. Also, this is not meant to be an exhaustive feature list, if you have an idea for a feature that you think will be a valuable addition to the package manager, feel free to start a discussion about it.

If you’re interested in participating in a particular evolution idea, please familarize yourself with the existing discussion on that topic and start participating in the discussion thread of that idea.

Nate Cook pitched a proposal to add an Array initializer with access to its unitialized buffer.

I’ve been thinking about a way of creating an array that would let us access the buffer of uninitialized memory, so that we could implement algorithms that don’t necessarily know the size in advance or need access to noncontiguous parts of an array.

There is currently no way to work with a buffer of uninitialized memory that then becomes a fully memory-managed Array. This limitation means that operations that don’t know the final size of their data in advance, or that need to access noncontiguous parts of an array, are less efficient than necessary, often requiring an extra copy. This proposal suggests a new initializer for Array and ContiguousArray that would provide access to a newly created array’s entire storage buffer.

Becca Royal-Gordon pitched a proposal that aims to clean up some of the lesser known rough edges in String interpolation.

So, everyone knows what a string interpolation looks like:

print("Hello, \(firstName)!")

But let’s talk about some other things you might write, perhaps because you hate compiler engineers. What do you think these do?

print("Hello, \()!")                                    // #1
print("Hello, \(first: firstName)!")                    // #2
print("Hello, \(firstName, lastName)!")                 // #3
print("Hello, \(first: firstName, last: lastName)!")    // #4

Most people I’ve spoken to say “produce an error message”, and they’re right about #1—it produces the error “expected expression in list of expressions”. Maybe not the clearest message, but it’s not technically wrong.

But the other three? They actually compile without complaint and form a tuple.

Finally

Do you wish to take a leap of faith?