Issue 141 (#473)

* Added starter bug

* First draft

Also updated gems

* Added PR

* Added forum entry and one starter bug

* Added new stuff

* remove sponsor block
* intro text
* typos

* Remove sponsor and text fixes

* Fixed typos

* Update 2019-08-22-issue-141.md

* Remove empty sections

Author: fassko

_drafts/2019-08-22-issue-141.md

@@ -1,56 +1,104 @@
 ---
 layout: post
 title: ! 'Issue #141'
-author: btb
-sponsor:
-    link: TODO
-    heading: TODO
-    body: TODO
-    displaylink: TODO
+author: fassko
 ---
 
-> TODO: intro comments
+Summer is almost over and it seems that the Swift community is getting ready for some big product announcements later this year. Nevertheless we had quite an intense last two weeks in the Swift.org open source projects.
 
 <!--excerpt-->
 
 {% include sponsor.html %}
 
 ### Starter tasks
 
-> TODO
+* [SR-11295](https://bugs.swift.org/browse/SR-11295) [Compiler] There should be a warning for unnecessary casts
+* [SR-11321](https://bugs.swift.org/browse/SR-11321) [SwiftPM] `generate-xcodeproj` does not generate relative search paths correctly
 
 ### Podcasts
 
-> TODO: Latest episode(s) of Swift Unwrapped & the Swift Community Podcast
+In the [latest Swift by Sundell podcast](https://www.swiftbysundell.com/podcast/54), [John Sundell](https://twitter.com/johnsundell), [Benedikt Terhechte](https://twitter.com/terhechte) and [Bas Broek](https://twitter.com/basthomas) dive into the new APIs and features in iOS 13 and iPadOS, as well as Swift 5.1.
 
 ### News and community
 
-> TODO
+[Cory Benfield](https://twitter.com/Lukasaoz) gave [a heads up](https://twitter.com/Lukasaoz/status/1161323863411777537) that if we are using SwiftNIO HTTP/2, we need to upgrade as soon as possible.
 
-### Commits and pull requests
+> All `swift-nio-http2` users, please update to `swift-nio-http2` version 1.5.0 urgently.
+>
+> A number of HTTP/2 server implementations have been discovered to be at risk of a number of different denial of service attacks. SwiftNIO HTTP/2 has been affected by several of these vulnerabilities. This disclosure covers all of them.
+> 
+> All SwiftNIO HTTP/2 versions between 1.0.0 and 1.4.0 inclusive are affected.
+
+[Julian Lettner](https://github.com/yln/) shared a [blog post](https://swift.org/blog/tsan-support-on-linux/) about the thread sanitizer for Swift on Linux. If you have any questions head down to the [forum discussion](https://forums.swift.org/t/swift-org-blog-thread-sanitizer-for-swift-on-linux/27872).
+
+> The Swift language guarantees [memory safety](https://docs.swift.org/swift-book/LanguageGuide/MemorySafety.html) in single threaded environments. However, conflicting accesses in multithreaded code lead to data races. Data races in Swift cause unexpected behavior and can even lead to memory corruption, breaking Swift’s memory safety. [Thread Sanitizer](https://developer.apple.com/documentation/code_diagnostics/thread_sanitizer) is a bug-finding tool that diagnoses data races at run time. It instruments code during compilation and detects data races when they happen during execution.
 
-> TODO
+[Bruno Rocha](https://twitter.com/rockthebruno) wrote a great [blog post](https://swiftrocks.com/using-lldb-manually-xcode-console-tricks.html) on advanced `lldb` tricks for Swift - injecting and changing code on the fly.
 
-### Accepted proposals
+[Ole Begemann](https://twitter.com/olebegemann) tweeted about [autodiscovery of test methods](https://twitter.com/olebegemann/status/1160846803274801152) on Linux and other non-Darwin platforms.
+It was introduced in [pull request 2174](https://github.com/apple/swift-package-manager/pull/2174).
 
-> TODO
+> Autodiscovery of test methods on Linux* is now a thing in recent Swift 5.1 snapshots. You should be able to delete LinuxMain.swift and run your tests with:
+> 
+> `swift test --enable-test-discovery`
 
-### Returned proposals
+[Joe Groff](https://twitter.com/jckarter) tweeted that [now you can implement](https://twitter.com/jckarter/status/1161298507527000064) the wrapper as a static subscript with access to `self`. This was done in [pull request 25884](https://github.com/apple/swift/pull/25884) by [Doug Gregor](https://github.com/DougGregor). Be careful and use this at your own risk!
 
-> TODO
+[Slava Pestov](https://twitter.com/slava_pestov) tweeted that [we could learn from JavaScript](https://twitter.com/slava_pestov/status/1160616505589030914) that delayed parsing is a cool trick.
+
+> Delayed parsing is a cool trick. I know JS implementations do it too. The idea is you can skip building AST for some parts of a source file. In order to correctly parse code following a delayed range, you still have to run the lexer - but it suffices to just count matching braces
+
+### Commits and pull requests
 
-### Rejected proposals
+[Jonas Devlieghere](https://github.com/JDevlieghere) merged [a pull request](https://github.com/apple/swift/pull/26673) that moves Xcode support to C++14. It's useful to mention that [LLVM and clang are now compiling with C++14](http://llvm.org/D66195) as well. You can discuss it [here](https://forums.swift.org/t/llvm-is-now-on-c-14/27931).
 
-> TODO
+[Doug Gregor](https://twitter.com/dgregor79) created [a pull request](https://github.com/apple/swift/pull/26700) that will simplify one-way constraints to Equal.
 
 ### Proposals in review
 
-> TODO
+A [new proposal](https://forums.swift.org/t/proposal-sswg-incubation-process-change-discourage-use-of-unsafe/27921) from the Swift Server Workgroup about an incubation process change. Feedback period will be till August 29.
+
+> When using *Unsafe* in Swift, Swift becomes as "safe" as C(++). [Research](https://msrc-blog.microsoft.com/2019/07/18/we-need-a-safer-systems-programming-language/) shows [that](https://langui.sh/2019/07/23/apple-memory-safety/) about [70%](https://alexgaynor.net/2019/aug/12/introduction-to-memory-unsafety-for-vps-of-engineering/) of the security vulnerabilities are related to memory safety issues.
+> 
+> Swift and SwiftNIO try to offer programmers fast and safe APIs which should mostly make the use of *Unsafe* constructs unnecessary. If that is not the case, we appreciate feature requests to add API allowing to use safe APIs to the respective projects.
 
 ### Swift Forums
 
-> TODO
+The Swift on Server Workgroup had a meeting on July 25th, 2019 and [Tanner Nelson](https://twitter.com/tanner0101) shared [notes](https://forums.swift.org/t/july-25th-2019/27732).
+
+[Ben Cohen](https://twitter.com/airspeedswift) started a discussion whether it's appropriate to provide a default implementation relying on `ObjectIdentifier`. This is a continued discussion from [SE-0261: Identifiable Protocol](https://forums.swift.org/t/accepted-se-0261-identifiable-protocol/27358).
+
+> To set expectations clearly: the proposal has been accepted and the default implementation will ship in Swift 5.1. There is no possibility of it being removed from that release, given the point we are at in the convergence of 5.1, regardless of the direction of this discussion.
+
+[Michael Gottesman](https://twitter.com/gottesmang) shared [news](https://forums.swift.org/t/stdlibcore-now-always-lowers-ownership-after-running-the-diagnostic-passes/27832) that `stdlibCore` now always lowers ownership after running the diagnostic passes.
+
+> ...I flipped the switch causing stdlibCore to always lower ownership /after/ running the diagnostic passes. This is a large milestone for ownership in general since this is the first time we have exposed some passes downstream of the Mandatory Inlining to ownership in the build itself (vs tests). It will ensure that changes in tree do not break basic functionality when we are in this mode (something that I have run into).
+
+[Suyash Srijan](https://twitter.com/suyashsrijan) pitched [a proposal](https://forums.swift.org/t/pitch-didset-semantics/27858) about `didSet` semantics.
+
+> This proposal aims to make a small change to the semantics of didSet, so that the call to the property's getter is skipped if the user does not refer to the oldValue in the body of the observer. It also aims to make another change, where the lack of a willSet and the presence of a unparameterised didSet could allow for modifications to happen in-place.
+
+[Saleem Abdulrasool](https://twitter.com/compnerd) shared that now [you can use the Swift Package Manager on Windows](https://forums.swift.org/t/swift-package-manager-on-windows-sure-why-not/27884).
+
+[Morten Bek Ditlevsen](https://forums.swift.org/u/Morten_Bek_Ditlevsen) started [a discussion](https://forums.swift.org/t/future-directions-of-property-wrappers/27934) about future directions of Property Wrappers.
+
+[Suyash Srijan](https://twitter.com/suyashsrijan) started [a discussion](https://forums.swift.org/t/class-constrained-protocol-extension-has-incorrect-mutatingness/27962) about class-constrained protocol extensions that have incorrect mutatingness.
+
+[Kelvin Ma](https://github.com/kelvin13) posted [a question](https://forums.swift.org/t/why-are-these-evolution-proposals-not-moving-forward/27996): why aren't some evolution proposals moving forward?
+
+> I’m opening this thread because one of my proposals, [Synthesized `Comparable` for pure enumerations](https://github.com/apple/swift-evolution/pull/1053), has been sitting with its swift evolution PR open for nearly a month with no action from core team members who would have the authority to bring it to review. the proposal text is finished, raised issues have been addressed, and its [implementation branch](https://github.com/apple/swift/pull/25696) has been untouched for about two months now. By all means, the proposal has fulfilled all the requirements to go to community review (except for CI tests, which can only be triggered by members with write-access), yet still, no review has been scheduled.
+
+[Marc Rasi](https://forums.swift.org/u/marcrasi) shared an idea about [building `.swiftmodules` for SourceKit](https://forums.swift.org/t/building-swiftmodules-for-sourcekit/28030)
+
+> I'm working on adding SourceKit to Google's internal source tooling. The architecture is a server that runs one instance of SourceKit per user, and uses those instances of SourceKit to serve requests from IDEs.
+>
+> To make this work on code that imports modules, I need to give SourceKit access to the appropriate ".swiftmodule" files.
+
+[Ben Langmuir](https://twitter.com/benlangmuir) noted that a preview version of [SourceKit-LSP](https://github.com/apple/sourcekit-lsp) is now included in the [nightly toolchain downloads](https://swift.org/download/#snapshots) for both Swift 5.1 Development and Trunk Development (`master`).
+
+[Dale Buckley](https://forums.swift.org/u/dlbuckley) started a discussion about [default protocol implementation inheritance behaviour](https://forums.swift.org/t/default-protocol-implementation-inheritance-behaviour-the-current-situation-and-what-if-anything-should-be-done-about-it/28049). The original bug was reported [here](https://bugs.swift.org/browse/SR-103).
+
 
 ### Finally
 
-> TODO: something funny/fun. tweet, link, etc.
+It is summertime now, need to do some [gardening](https://github.com/apple/swift/pull/26650).