Issue 94 (#331)

* Issue 94

* Minor edits

* [94] Colon, not comma

Not to be a stickler about this, but I do prefer a colon here, since
it's followed by a list of things that happened in Swift development,
and I think its usage here is grammatically correct. Let me know if
the first sentence needs to be rewritten altogether, but I think if
it's going to stay as-is then the colon isn't a bad choice here.

Author: modocache

_drafts/2017-11-09-issue-94.md

@@ -0,0 +1,168 @@
+---
+layout: post
+title: ! 'Issue #94'
+author: modocache
+---
+
+This week in Swift development: the Swift team created several fun new starter
+tasks, Doug Gregor fixed a nasty bug in Objective-C interop, and the mailing
+lists were abuzz with several exciting Swift Evolution proposals. Adjust your
+Apple Watches -- it's "Swift Weekly Brief O'Clock"!
+
+<!--excerpt-->
+
+{% include sponsor.html %}
+
+### Starter tasks
+
+* [SR-6264](https://bugs.swift.org/browse/SR-6264): This task is to extract
+  duplicated code in three methods. The methods each check whether a declaration
+  may be used externally based on its access level (`public`, `internal`, etc.).
+* [SR-6272](https://bugs.swift.org/browse/SR-6272): This task is to add better
+  diagnostics for common numerical conversions. For example, the Swift compiler
+  should be able to suggest a cast for source code that attempts to multiply an
+  `Int` and a `CGFloat`.
+* [SR-6312](https://bugs.swift.org/browse/SR-6312): To clone the apple/swift
+  family of projects, and to pull in the latest changes to those clones,
+  contributors use a Python script: `utils/update-checkout --clone` to clone,
+  and just `utils/update-checkout` to update. This task is to modify
+  `utils/update-checkout` so that it suggests using `--clone` if the user
+  attempts to update before cloning.
+
+If you're looking for a meatier task, you may want to try
+[SR-3423](https://bugs.swift.org/browse/SR-3423), which would allow enum cases
+with tuple raw values. In other words, you could make this possible in Swift:
+
+{% highlight swift %}
+enum Status: (Int, String) {
+  case OK = (200, "OK")
+  case NotFound = (404, "Not Found")
+}
+{% endhighlight %}
+
+{% include task_remind.html %}
+
+### News and community
+
+[Arek Holko](https://twitter.com/arekholko) [posted](https://github.com/fastred/Optimizing-Swift-Build-Times)
+a checklist for diagnosing and improving long compile times in Swift projects.
+
+[Brian Gesiak](https://twitter.com/modocache) continued his Swift compiler series with
+[*An Introduction to the Swift Compiler Driver*](https://modocache.io/introduction-to-the-swift-compiler-driver).
+
+### Commits and pull requests
+
+[Doug Gregor](https://twitter.com/dgregor79) [fixed](https://github.com/apple/swift/pull/12823)
+an issue in which Swift's ClangImporter would use a stale AST cache for
+properties of Objective-C classes, which affected how declarations would be
+imported into Swift. This most likely fixes an issue in which
+`-[UIView addGestureRecognizer:]` would sometimes be imported as
+`UIView.add(_:)`.
+
+[John McCall](https://twitter.com/pathofshrines) [added](https://github.com/apple/swift/pull/12789)
+a way to represent coroutines in Swift's intermediate language, SIL.
+
+[Daniel Dunbar](https://twitter.com/daniel_dunbar) opened a [pull request](https://github.com/apple/swift-llbuild/pull/195)
+that improves the cancellation model in llbuild. Previously, cancelling a build
+in llbuild would not stop work that was in-flight, but instead merely have those
+units of work finish normally and then report a "cancelled" status. The change
+cancels the work, preventing it from completing as it normally would.
+
+[Mark Lacey](https://github.com/rudkx) opened a [pull request](https://github.com/apple/swift/pull/12682)
+to fix edge cases in which implicitly-unwrapped optional (IUO) usage that was
+disallowed by [SE-0054](https://github.com/apple/swift-evolution/blob/master/proposals/0054-abolish-iuo.md)
+was considered valid in Swift 3 and 4. This is a "source-breaking" change for
+codebases that used syntax that, while being technically invalid in Swift 3 and
+4, would not result in errors being emitted by the Swift compiler until now.
+He also opened a [pull request](https://github.com/apple/swift-corelibs-foundation/pull/1306)
+that removes a soon-to-be-disallowed IUO from swift-corelibs-foundation.
+
+[Philippe Hausler](https://twitter.com/phausler) opened a [pull request](https://github.com/apple/swift-corelibs-foundation/pull/1305)
+to update swift-corelibs-foundation with the latest CoreFoundation source code
+included in macOS High Sierra.
+
+[Francis Ricci](https://github.com/fjricci) opened a [pull request](https://github.com/apple/swift/pull/12702)
+that allows Objective-C to be imported even on non-Darwin platforms. Although
+I would imagine almost no developers use an Objective-C runtime outside of
+Darwin, this does decouple some ClangImporter behavior from its host platform,
+which seems like a good thing to do.
+
+### Proposals in review
+
+The [review](https://lists.swift.org/pipermail/swift-evolution-announce/2017-November/000406.html)
+of _[SE-0187](https://github.com/apple/swift-evolution/blob/master/proposals/0187-introduce-filtermap.md):
+Introduce `Sequence.filterMap(_:)`_ has begun and runs through November 14th, 2017.
+
+> We propose to deprecate the controversial version of a `Sequence.flatMap`
+  method and provide the same functionality under a different, and potentially
+  more descriptive, name. [...] The name being `filterMap(_:)` as we believe it
+  best describes the intent of this function. [...] Since the old function will
+  still be available (although deprecated) all the existing code will compile,
+  producing a deprecation warning and a fix-it.
+
+The [review](https://lists.swift.org/pipermail/swift-evolution-announce/2017-November/000407.html)
+of _[SE-0188](https://github.com/apple/swift-evolution/blob/master/proposals/0188-stdlib-index-types-hashable.md):
+Make stdlib index types `Hashable`_ begins now and runs through November 14th, 2017.
+
+> This proposal would add `Hashable` conformance to all the index types in the
+  standard library. With that done, `[Int]`, `String`, and all other standard
+  libary collections would have the same behavior when using subscripts in key
+  paths.
+
+### Mailing lists
+
+Tony Parker [solicited](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171106/040959.html)
+public feedback on a Foundation-only proposal that has been evaluated internally
+at Apple. The proposal is for a mechanism to encode and decode JSON keys in
+order to, for example, automatically deserialize `snake_case_keys` as
+`camelCaseKeys`.
+
+[Dave DeLong](https://twitter.com/davedelong) [proposed](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171030/040862.html)
+allowing custom operators to take parameters with default arguments. He also
+provided an implementation with the proposal.
+
+Ben Cohen [pitched](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171106/041053.html)
+eliminating `IndexDistance` from `Collection`. He [tweeted](https://twitter.com/AirspeedSwift/status/928376958357876736)
+that it would make writing generic algorithms easier.
+
+Alejandro Alonso [proposed](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170904/039605.html)
+adding standard library functions for generating random numbers, as well as for
+randomizing the order of an array ("shuffling"). The proposal aims to address
+a pain point in cross-platform Swift development, since different platforms
+use different randomization functions (`arc4random()` on Darwin, `random()` or
+`rand()` on Linux, etc.).
+
+[Jacob Bandes-Storch](https://twitter.com/jtbandes) [re-proposed](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171106/040950.html)
+adding an `allCases` static property to enums. The proposal was widely popular
+when it was first proposed for Swift 3, but ultimately deferred. If it's
+accepted this time, we may see it in Swift 5.
+
+Discussion of [Graydon Hoare](https://twitter.com/graydon_pub)'s Swift Evolution
+[proposal draft](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171023/040652.html),
+which adds a target environment platform condition to the Swift language,
+continues. The patch proposes adding a `#if targetEnvironment(simulator)`
+condition. Replies to the proposal began to discuss what attributes should be
+available as platform conditions. This week, Graydon [pointed out](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171030/040819.html)
+that whether the compilation target was a simulator or not was encoded in the
+target triple, a decision made recently in LLVM, so discussions of whether it
+should be encoded at all should be done on the LLVM mailing lists.
+
+[Brent Royal-Gordon](https://twitter.com/brentdax) [asked](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171030/040863.html)
+about how he could update his once deferred proposal, [SE-0132](https://github.com/apple/swift-evolution/blob/master/proposals/0132-sequence-end-ops.md),
+which proposes renaming several `Sequence` and `Collection` methods such that
+they follow a consistent naming scheme.
+
+Erik Eckstein [proposed](https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20171030/005774.html)
+deprecating the `-Ounchecked` compiler option. This optimization mode removes
+runtime safety checks, and adds additional complexity to the standard library
+code, which must behave differently at that optimization level.
+
+[Rick Ballard](https://twitter.com/rballard) [responded](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171106/040953.html)
+to questions about SwiftPM's roadmap for Swift 5.
+
+Kelvin Ma [pointed out](https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20171106/005811.html)
+that Swift has potential to layout some enums using fewer bytes.
+
+### Finally
+
+Did you [remember](https://twitter.com/lapcatsoftware/status/926911250507993088) to adjust for DST? (That's "delightful Swift time", of course.)