Issue 107

_drafts/2018-04-19-issue-107.md

@@ -4,48 +4,111 @@ title: ! 'Issue #107'
 author: btb
 ---
 
-> TODO: intro comments
+Over the last two weeks we have seen a lot of proposals that have been discussed (and accepted), and it is likely we will see many of these proposals being released in either Swift 4.2 or Swift 5.
 
 <!--excerpt-->
 
 ### Starter tasks
 
-> TODO
+- [SR-7445](https://bugs.swift.org/browse/SR-7445) [Compiler] Call Expressions Need Better Assignment Diagnostics
+- [SR-7398](https://bugs.swift.org/browse/SR-7398) [Compiler] Preserve availability on ObjC subscript getters and setters
 
 {% include task_remind.html %}
 
 ### Swift Unwrapped
 
-> TODO: Latest episode of Swift Unwrapped
+In [Episode 53](https://spec.fm/podcasts/swift-unwrapped/130955) Jesse and JP discuss Swift for Tensorflow, which was announced in a talk by Chris Lattner at TensorFlow Dev Summit 2019.
+
+In [Episode 54](https://spec.fm/podcasts/swift-unwrapped/130967) Jesse and JP discuss some of the recent proposals on `Collection` and `Sequence`.
 
 ### News and community
 
-> TODO
+[Slava Pestov](https://twitter.com/slava_pestov) wrote [a blog post](https://medium.com/@slavapestov/behind-the-scenes-improvements-in-swift-4-1-269dd56e30c2) on some of the less-visible improvements in Swift 4.1.
+
+[Brian Gesiak](https://twitter.com/modocache) wrote [a blog post](https://modocache.io/swift-compiler-diagnostics-part-1) on how the Swift compiler emits diagnostics.
 
 ### Commits and pull requests
 
-> TODO
+[Pavel Yaskevich](https://github.com/xedin) merged [a pull request](https://github.com/apple/swift/pull/15843) that makes progresson fully implementing [SE-0110](https://github.com/apple/swift-evolution/blob/master/proposals/0110-distingish-single-tuple-arg.md): *Distinguish between	single-tuple and multiple-argument function types*.
+
+[Slava Pestov](https://twitter.com/slava_pestov) merged [a pull request](https://github.com/apple/swift/pull/15894) to improve the Swift Intermediate Language ([SIL](https://github.com/apple/swift/blob/master/docs/SIL.rst))'s deserialization in `-Onone` mode — by 25% on a large project with batch mode! 👏
 
 ### Accepted proposals
 
-> TODO
+[SE-0201](https://github.com/apple/swift-evolution/blob/master/proposals/0201-package-manager-local-dependencies.md): *Package Manager Local Dependencies* was [accepted](https://forums.swift.org/t/se-0201-package-manager-local-dependencies/11286/17).
+
+> Feedback was positive, and the proposal is accepted. Thanks to everyone who participated!
+
+[SE-0205](https://github.com/apple/swift-evolution/blob/master/proposals/0205-withUnsafePointer-for-lets.md): *`withUnsafePointer(to:_:)` and `withUnsafeBytes(of:_:)` for immutable values* was [accepted](https://forums.swift.org/t/accepted-se-0205-withunsafepointer-to-and-withunsafebytes-of-for-immutable-values/11966).
+
+> The review of this proposal is now over and the proposal has been accepted.
+>
+> Thanks for everyone for participating in the review.
+
+[SE-0206](https://github.com/apple/swift-evolution/blob/master/proposals/0206-hashable-enhancements.md): *Hashable Enhancements* was [accepted with revisions](https://forums.swift.org/t/accepted-se-0206-hashable-enhancements/11675/115).
+
+> `init(seed:)`'s behavior may be misleading to users who expect it to enable deterministic hashing, and has no real benefit over a collection implementation seeding the hasher directly with combine calls.
+>
+> [..] the many `combine(bits:)`overloads on `Hasher` that take fixed-sized integers don’t need to be public API.
+>
+> The core team recommends that `Hasher.finalize()` be made a `__consuming` nonmutating method instead of a mutating method that invalidates the `Hasher` value.
+> 
+> Thanks again to everyone for participating in the review!
+
+[SE-0208](https://github.com/apple/swift-evolution/blob/master/proposals/0208-package-manager-system-library-targets.md): *Package Manager System Library Targets* was [under review](https://forums.swift.org/t/se-0208-package-manager-system-library-targets/11735) and consequently [accepted](https://forums.swift.org/t/se-0208-package-manager-system-library-targets/11735/16).
+
+> This proposal introduces a new type of target "system library target", which moves the current system-module packages feature from package to target level.
+>
+> The package manager currently supports "system-module packages" which are intended to adapt a system installed dependency to work with the package manager. However, this feature is only supported on package declarations, which mean libraries that need it often need to create a separate repository containing the system package and refer to it as a dependency.
+>
+> Our original motivation in forcing system packages to be declared as standalone packages was to encourage the ecosystem to standardize on them, their names, their repository locations, and their owners. In practice, this effort did not work out and it only made the package manager harder to use.
 
-### Returned proposals
+---
+
+> Feedback was positive, and the proposal is accepted. Thanks to everyone who participated!
+
+[SE-0209](https://github.com/apple/swift-evolution/blob/master/proposals/0209-package-manager-swift-lang-version-update.md): *Package Manager Swift Language Version API Update* was [under review](https://forums.swift.org/t/se-0209-package-manager-swift-language-version-api-update/11815) and consequently [accepted with revisions](https://forums.swift.org/t/accepted-se-0209-package-manager-swift-language-version-api-update/11962).
 
-> TODO
+> This proposal changes the current `Package.swift` manifest API for declaring for Swift language versions from freeform Integer array to a new `SwiftVersion` enum array.
+>
+> The Swift compiler now allows `4.2` as an accepted value of Swift version flag (`-swift-version`). The `swiftLanguageVersions` API in `Package.swift` currently accepts an integer array and we need to update this API in order for packages to declare this language version if required.
+
+---
 
-### Rejected proposals
+> Feedback was positive, and the proposal is accepted with revisions. Thanks to everyone who participated!
+>
+> We considered making `SwiftVersion` a struct which conforms to `ExpressibleByIntegerLiteral` and `ExpressibleByStringLiteral`. However, we think the enum approach is better for several reasons:
+>
+> - It is consistent with the C/C++ language version settings.
+> - The package authors can easily tell which versions are available.
+> - The package authors don't need to concern themselves with how to spell a valid version.
 
-> TODO
+### Extended proposals
 
-### Proposals in review
+The review of [SE-0202](https://github.com/apple/swift-evolution/blob/master/proposals/0202-random-unification.md): *Random Unification* was [extended](https://forums.swift.org/t/se-0202-random-unification/11313/149) to get feedback on its design.
 
-> TODO
+> The nature of the generator API implies that the generators must be reference-y, since they aren’t passed inout to functions like `shuffle`, but aren’t *required* to be reference types.
+>
+> The team thinks making the `random(in: Range<T>)` family free functions, rather than static methods on `T`, may help with discoverability.
+>
+> The team felt that `Collection.randomElement` would work better than `Collection.random`. Unlike `.first` or `.max`, the word “random” doesn’t noun well, so adding “Element” improves readability.
+>
+> The core team believes it would be better to leave implementation details of the default source to the individual platforms, rather than defining the implementation for each platform as part of the proposal.
 
 ### Swift Forums
 
-> TODO
+[Erica Sadun](http://twitter.com/ericasadun/status/970754573609484288) pitched [a proposal](https://forums.swift.org/t/introducing-role-keywords-to-reduce-hard-to-find-bugs/6113) to introduce keywords in protocols that help eliminate bugs.
+
+> We'd love to know what you think of our idea, which is to introduce "role" keywords. Roles allow the compiler to automatically check the intended use of a extension member definition against its protocol declarations, and emit errors, warnings, and fixits as needed.
+
+Erica also [shared some thoughts](https://forums.swift.org/t/rfd-countedset/11792) about adding a `CountedSet` to Swift.
+
+> I’m looking to take the community temperature about adding `CountedSet` to Swift Foundation/Standard Library.
+
+[Joey KL](https://github.com/JoeyKL) pitched [a proposal](https://forums.swift.org/t/rename-protocols-that-use-self-or-associated-types-to-constraints-and-declare-them-as-such/11944) to rename protocols that use `Self` or associated types to "constraints".
+
+> There are two different types of protocols in Swift and they behave completely differently. Normal protocols are like any other type, use dynamic dispatch and allow for heterogenous mixtures of different implementations (similar to objects that inherit from the same base class). On the other hand, constraint protocols (distinguished only by having an `associatedtype`, or even more subtle, just using `Self`) use static dispatch, can never be used like a type, and can only be used to restrict which real types can be used for a generic function or new concrete type.
 
 ### Finally
 
-> TODO: something funny/fun. tweet, link, etc.
+Swift's goal [really is world domination](https://twitter.com/Javi/status/985563399533686786)... 🏎