[48] draft update

Author: jessesquires

_drafts/2016-12-01-issue-48.md

@@ -14,6 +14,8 @@ There's a new [swift-server](https://github.com/swift-server) organization on Gi
 
 Greg Heo wrote two great articles about two of the types in standard library: [*CollectionOfOne*](https://swiftunboxed.com/open-source/CollectionOfOne/) and [*IteratorOverOne*](https://swiftunboxed.com/open-source/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](https://github.com/alblue/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](https://github.com/apple/swift/pull/5935) 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](https://twitter.com/slava_pestov/status/802942139873173504), resolved a 2013 FIXME. That code was so old, it could have been written on a newly updated Mac Pro. 😉
@@ -22,6 +24,14 @@ Alex Blewitt opened a [pull request](https://github.com/apple/swift/pull/5903) t
 
 Hugh Bellamy [added support](https://github.com/apple/swift/pull/5904) for building Swift on Windows with [MSVC](https://en.wikipedia.org/wiki/Visual_C%2B%2B). There are corresponding pull requests on [swift-clang](https://github.com/apple/swift-clang/pull/45) and [swift-llvm](https://github.com/apple/swift-llvm/pull/33). All 3 pull requests require merging in order for Swift to build successfully on Windows.
 
+Roman Levenstein [reduced](https://github.com/apple/swift/pull/5979) the compiler memory usage during the LLVM code-generation and optimization phases by roughly by 15-20 percent.
+
+Ankit Aggarwal [added](https://github.com/apple/swift-package-manager/pull/823) performance tests to SwiftPM for "real world" packages, [including](https://github.com/apple/swift-package-manager/pull/823/files#diff-3e7409122da942c39a66fc6b6a6dba7bR124) Kitura, Zewo, Perfect, and SourceKitten.
+
+Ben Ng [submitted](https://github.com/apple/swift/pull/5978) changes to the SILOptimizer to improve the performance of appending to `Array`. *"This makes `myArray += [42]` equivalent to `myArray.append(42)`, which results in a 6x speedup."*
+
+Alex Blewitt [implemented](https://github.com/apple/swift-corelibs-foundation/pull/727) the remaining parts of `NSDecimal` and `NSDecimalNumber` in corelibs-foundation.
+
 Chris Bailey has [posted the meeting minutes](https://github.com/swift-server/work-group/pull/52) from the Swift Server Work Group HTTP kick-off meeting.
 
 ### Accepted proposals
@@ -46,6 +56,25 @@ Proposal [SE-0145](https://github.com/apple/swift-evolution/blob/master/proposal
 
 > 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](https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20161128/003567.html) 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](https://mulle-objc.github.io). 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](https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20161128/003585.html):
+
+> 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.
+
+[Weekend project, anyone?](https://twitter.com/modocache/status/804003571897368576)
+
+Nate Cook [pitched an idea](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20161128/029095.html) 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 `UnsafeBufferPointer` types to be their own slice type, like the `UnsafeRawBufferPointer` types. This is a minor change in the subscript API of `UnsafeBufferPointer` and `UnsafeMutableBufferPointer`, but constitutes a change to the standard library's ABI, as it can't be solved through type aliasing.
+
 ### Finally
 
-> TODO: something funny/fun. tweet, link, etc.
+And finally — [only in Silicon Valley](https://twitter.com/dgregor79/status/804026200863739904).