More draft work

References #502

Author: BasThomas

_drafts/2020-03-12-issue-155.md

@@ -20,22 +20,59 @@ In episode 85 of Swift Unwrapped, Jesse and JP talk [about Swift on Windows and
 announcing ArgumentParser, an open-source library that makes it straightforward
 — even enjoyable! — to parse command-line arguments in Swift.
 
+Swift 5.1.5 [has been released](https://swift.org/download/).
+
 ### Commits and pull requests
 
-https://github.com/apple/swift/pull/30174
+[Doug Gregor](https://twitter.com/dgregor79) merged [a pull request](https://github.com/apple/swift/pull/30174)
+that adds `switch` statement support to function builders!
+
+In that pull request, Doug pushed [a commit](https://github.com/apple/swift/commit/ea8d143f6425e4db7ba78df82776cc075add1e22)
+after a code review from [John McCall](https://twitter.com/pathofshrines) who
+noted a subtle omission in constraint generation that affected the semantics of
+switch statements in function builders.
+
+Yay for code review. @pathofshrines noted a subtle omission in constraint generation that affected the semantics of switch statements in function builders. The fix was trivial but the implications are really interesting
+
+[David Smith](https://twitter.com/Catfish_Man) and [Tim K](https://github.com/tbkka) merged [a pull request](https://github.com/apple/swift/pull/30329) that provides a speedup for bridging
+ObjC collections containing NSStrings.
 
-https://github.com/apple/swift/commit/ea8d143f6425e4db7ba78df82776cc075add1e22
+[Kuba (Brecka) Mracek](https://twitter.com/kubamracek) merged [a pull request](https://github.com/apple/swift/pull/30112),
+upstreaming arm64e support for Swift.
 
-https://github.com/apple/swift/pull/30329
+Also:
 
-https://github.com/apple/swift/pull/30112
+> this means we finally won’t have a billion arm64e merge conflicts every
+single week
+
+Pretty neat!
 
 ### Proposals in review
 
 [SE-0280](https://github.com/apple/swift-evolution/blob/master/proposals/0280-enum-cases-as-protocol-witnesses.md): *Enum cases as protocol witnesses* is [under review](https://forums.swift.org/t/se-0280-enum-cases-as-protocol-witnesses/34257).
 
+> The aim of this proposal is to lift an existing restriction, which is that
+enum cases cannot participate in protocol witness matching.
+>
+> Currently, Swift has a very restrictive protocol witness matching model where
+a protocol witness has to match _exactly_ with the requirement, with some
+exceptions (see [Protocol Witness Matching Manifesto](https://forums.swift.org/t/protocol-witness-matching-mini-manifesto/32752)).
+
 [SE-0279](https://github.com/apple/swift-evolution/blob/master/proposals/0279-multiple-trailing-closures.md): *Multiple Trailing Closures* is [under review](https://forums.swift.org/t/se-0279-multiple-trailing-closures/34255).
 
+> Since its inception, Swift has supported _trailing closure_ syntax, which is
+a bit of syntactic sugar that makes passing closures more ergonomic. Trailing
+closures have always had two restrictions that limited their applicability.
+First, that any call is limited to a single trailing closure, making the
+feature awkward or even unusable when an API has more than one callback. This
+limitation was noticed [very early on in Swift's
+lifetime](https://www.natashatherobot.com/swift-trailing-closure-syntax/) as
+"the" problem with trailing closure syntax. Second, that a trailing closure
+argument does not provide an argument label, which can lead to call sites that
+are less clear. This proposal removes both restrictions by providing an
+unambiguous syntax for providing multiple, labeled trailing closures in a call,
+leading to clearer and more consistent code.  
+
 ### Swift Forums
 
 https://forums.swift.org/t/tuples-conform-to-equatable-comparable-and-hashable/34156