Welcome back to the weekly! There was definitely some quiet time during the holidays in the US, but the repos are back to buzzing with activity.
News and community
There’s a new swift-server organization on GitHub for the Server APIs Project. There’s currently only one repository, work-group, which contains meeting notes for the various sub-teams — HTTP, networking, and security.
Greg Heo wrote two great articles about two of the types in standard library: CollectionOfOne and IteratorOverOne. Each post dives into the implementation details of the types, explaining each piece one by one. (See what I did there? 😄)
This isn’t new, but I just discovered Alex Blewitt’s open source project, SILInspector — An application for experimenting with Swift’s Intermediate Language. This might be interesting for you if you want to learn more about SIL.
Commits and pull requests
Slava Pestov completed some major refactoring work regarding function types in the AST. The
PolymorphicFunctionType class was removed and subsumed by
GenericFunctionType. This work, the culmination of two years chipping away at technical debt in Swift generics, resolved a 2013 FIXME. That code was so old, it could have been written on a newly updated Mac Pro. 😉
Hugh Bellamy added support for building Swift on Windows with MSVC. There are corresponding pull requests on swift-clang and swift-llvm. All 3 pull requests require merging in order for Swift to build successfully on Windows.
Roman Levenstein reduced the compiler memory usage during the LLVM code-generation and optimization phases by roughly by 15-20 percent.
Ben Ng submitted changes to the SILOptimizer to improve the performance of appending to
Array. “This makes
myArray +=  equivalent to
myArray.append(42), which results in a 6x speedup.”
Alex Blewitt implemented the remaining parts of
NSDecimalNumber in corelibs-foundation.
Chris Bailey has posted the meeting minutes from the Swift Server Work Group HTTP kick-off meeting.
The proposal has been accepted for Swift 4 phase 1. Reception was almost unanimously positive, and while there was valid discussion and concern about the limitations of the initial model as proposed and its impact on the future direction of Swift’s generics model, the core team agrees that this is an independently useful and valuable expansion of the generics model that leaves the door open to future elaboration. Thank you Doug for writing and revising the proposal, and thank you to everyone who participated in its review!
The proposal received no feedback, but as the core team already agreed it is the right direction we will move forward with accepting and implementing it.
Proposals in review
This is a proposal for adding package manager features to “pin” or “lock” package dependencies to particular versions.
From Jordan Rose on a thread about conditional conformance to protocols:
Rule of thumb: overloads are resolved statically, protocol requirements are invoked dynamically. You cannot get dynamic behavior out of just overloads, ever.
Brian Gesiak started a thread about modifying Swift’s build system to enable/disable Objective-C inter-op for any platform, which would allow Objective-C inter-op on non-Apple platforms.
Over the weekend I learned of the mulle-objc project. It boasts an Objective-C compiler and runtime that works on Linux.
Now, I don’t know if Swift’s Objective-C inter-op will work completely with mulle-objc, but I did a bit of experimenting over the weekend, and it seems possible. But one obstacle is the fact that the Swift build system conflates “an Apple target” with “capable of Objective-C inter-op.” To even start working with mulle-objc, I had to remove a lot of
#ifdef __APPLE__in the code.
Joe Groff replied:
To be clear, I didn’t mean to discourage you (or anyone else watching) from adding support for non-Apple Objective-C platforms; I only wanted to make it clear that it almost definitely won’t Just Work by trying to compile the existing code for a non-Apple target. Like John said, we should leverage higher-level interfaces in Clang’s CodeGen to emit ObjC metadata; right now, we hardcode the Apple layouts of everything.
Nate Cook pitched an idea for a proposal, Normalize Slice Types for Unsafe Buffers.
Hello all — This is a proposal for a fairly minor change in slicing behavior for unsafe buffers.
This proposal changes Swift’s typed
UnsafeBufferPointertypes to be their own slice type, like the
UnsafeRawBufferPointertypes. This is a minor change in the subscript API of
UnsafeMutableBufferPointer, but constitutes a change to the standard library’s ABI, as it can’t be solved through type aliasing.
And finally — only in Silicon Valley.