Welcome to issue 49! As of December 3, Swift has been open source for 1 full year. 😱 🎂 Can you believe it? I’m not sure if it is harder to believe that this was Swift’s first year of open source development, or that it has only been 1 year. Congrats to the Core Team, contributors, and community!

Starter tasks

  • SR-3181: [Compiler, Docs] The Swift man page is woefully out of date.
  • SR-3254: [Compiler] Diagnostics are unhelpful/confusing for compound function name references.
  • SR-3207: [Compiler] Segmentation fault with Objective-C parameter of type (NSError* __autoreleasing __nonnull * __nullable)

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

News and community

Ole Begemann wrote an article on The RawRepresentable Protocol in Swift. If you didn’t know, RawRepresentable isn’t limited to only enum types! Great read.

Brian King wrote about method dispatch in Swift. Chris Lattner summarized the article well: “A very thorough summary of how method dispatch works in various parts of Swift.”

Swift server work group

Chris Bailey posted the agendas for the first HTTP stream meeting and the first Security stream meeting. The meetings are taking place on December 12 and 14, respectively. Note that Chris has to coordinate these meetings among stakeholders in central Europe, the UK, east coast US, and west coast US. That feat alone deserves some kind of award. 😄

Commits and pull requests

Robert Widmann implemented proposal SE-0075: Adding a Build Configuration Import Test.

David Jones further improved the performance of JSON serialization on Linux in corelibs-foundation. It looks like improvements range from 1.2-2.2x speed ups.

Slava Pestov continued his factoring of the AST from last week, this time completely removing SubstitutedType. “Swift.swiftmodule is 670KB smaller now.” 🎉

Xi Ge fixed a few IDE crashers: 016, 091, 012.

Boris Bügling added support for build cancellation in swift-llbuild.

Accepted Proposals

Proposal SE-0145: Package Manager Version Pinning was accepted.

This was a revision of a previous proposal, and the feedback to this revised version was generally positive. Most of the feedback and discussion was about what the workflow and default behavior should be for various use cases. There was also some feedback about the name (“pinning” vs “locking”), and feedback that the proposed new JSON file be formatted in a way that is easily diffable. There seemed to be broad agreement that the underlying feature being proposed is a good and important improvement.

Thank you to Daniel Dunbar for writing this proposal and driving this discussion forward.

Proposals in review

Proposal SE-0147: Move UnsafeMutablePointer.initialize(from:) to UnsafeMutableBufferPointer by Ben Cohen is under review.

The version of UnsafeMutablePointer.initialize(from:) that takes a Collection should be deprecated in favor of a new method on UnsafeMutableBufferPointer that takes a Sequence, with a goal of improving memory safety and enabling faster initialization of memory from sequences. Similarly, UnsafeMutableRawPointer.initializeMemory(as:from:) should be deprecated in favour of a new UnsafeMutableRawBufferPointer.initialize(as:from:).

UnsafeMutablePointer.initialize(from:) underpins implementations of collections, such as Array, which are backed by a buffer of contiguous memory. When operations like Array.append are implemented, they first ensure their backing store can accommodate the number of elements in a source collection, then pass that collection into the initialize method of their backing store.

Unfortunately there is a major flaw in this design: a collection’s count might not accurately reflect the number of elements returned by its iterator. For example, some collections can be misused to return different results on each pass. Or a collection could just be implemented incorrectly.

If the collection’s count ends up being lower than the actual number of elements yielded by its iterator, the caller may not allocate enough memory for them. Since UnsafeMutablePointer.initialize(from:) does not receive a limiting capacity, this method would then scribble past the end of the buffer, resulting in undefined behaviour.

Mailing lists

Ankit Aggarwal announced new features in SwiftPM.

SwiftPM has a brand new dependency resolver. It was hidden behind a flag (--enable-new-resolver) while we developed and tested it but now it is the default resolver, starting from snapshots released on December 7, 2016. It is worth noting that, dependencies are no longer cloned into Packages/ directory, they will be cloned into the build directory (but that is an implementation detail as mentioned in the editable packages proposal). This means you can remove this directory when using the new resolver.

SwiftPM has two new major features built on top of the new resolver:

continue reading…

Finally

And finally — When I change 1 line in a unit test… 😄