Issue #49 08 Dec 2016
Written by: Jesse Squires
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!
- 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)
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.
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
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.
Boris Bügling added support for build cancellation in swift-llbuild.
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
The version of
UnsafeMutablePointer.initialize(from:)that takes a
Collectionshould be deprecated in favor of a new method on
UnsafeMutableBufferPointerthat 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
UnsafeMutablePointer.initialize(from:)underpins implementations of collections, such as
Array, which are backed by a buffer of contiguous memory. When operations like
Array.appendare implemented, they first ensure their backing store can accommodate the number of elements in a source collection, then pass that collection into the
initializemethod of their backing store.
Unfortunately there is a major flaw in this design: a collection’s
countmight 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
countends 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.
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:
And finally — When I change 1 line in a unit test… 😄