Issue #179 draft

Gemfile.lock

@@ -237,7 +237,7 @@ GEM
       jekyll (>= 3.5, < 5.0)
       jekyll-feed (~> 0.9)
       jekyll-seo-tag (~> 2.1)
-    minitest (5.14.3)
+    minitest (5.14.4)
     multipart-post (2.1.1)
     nap (1.1.0)
     no_proxy_fix (0.1.2)

_drafts/2021-02-25-issue-179.md

@@ -0,0 +1,124 @@
+---
+layout: post
+title: ! 'Issue #179'
+author: fassko
+sponsor:
+    link: TODO
+    heading: TODO
+    body: TODO
+    displaylink: TODO
+---
+
+This month we are [celebrating](https://swift.org/blog/black-history-month/) Black History Month, which makes this a good time to recognize those Swift community members who have had a tremendous impact on all of us. I want to thank them and everyone else who enriches and moves our community forward.
+
+It's sad to see that [Swift for TensorFlow](https://github.com/tensorflow/swift) has been archived. On a positive note, the project shows us that Swift can be used for advanced experiments in machine learning.
+
+Lately, I have been enjoying discussions on [Clubhouse](https://www.joinclubhouse.com), the drop-in audio chat app. There is already a large Swift community putting on events like Ladies Who Code, daily get-togethers, interview coaching, even teaching Swift — thanks to [Stephanie Chiu](https://twitter.com/stephanielatte_), [Ting Becker](https://twitter.com/Teekachu1), [Vivian Phung](https://twitter.com/vivianphung), [Paul Hudson](https://twitter.com/twostraws), and [Majid Jabrayilov](https://twitter.com/mecid) for setting up some of these rooms. 
+
+We still have several [sponsorship slots](/sponsorship) available. Please reach out to me [through email](mailto:fassko@gmail.com), or [say hello on Twitter](https://twitter.com/swiftlybrief).
+
+Thank you. Now it's time for the news!
+
+<!--excerpt-->
+
+{% include sponsor.html %}
+
+### Starter tasks
+
+- [SR-14221](https://bugs.swift.org/browse/SR-14221) [Compiler] Add tricky parsing test case.
+
+### News and community
+
+[Holly Borla](https://twitter.com/hollyborla) and [Kristina Fox
+](https://twitter.com/krstnfx/) wrote an [excellent article](https://swift.org/blog/black-history-month/) celebrating Black History Month. They have curated a handful of outstanding contributions from the Black Swift community to acknowledge and celebrate their impact on the Swift ecosystem.
+
+The Swift language has been included in the [Google Summer of Code](https://summerofcode.withgoogle.com/) this year again. The program is currently collecting ideas, matching them with mentors, and slowly putting them up on the (work in progress) [Swift.org - Project Ideas for GSoC 2021](https://swift.org/gsoc2021/) site.
+
+Robert Pieta shared a great [article](https://www.advancedswift.com/typealias-examples/) explaining variable, tuple, closure, and generic typealias in Swift.
+
+[Tibor Bödecs](https://twitter.com/tiborbodecs) wrote an article explaining the Swift compiler for beginners.
+
+### Commits and pull requests
+
+[Luciano Almeida](https://github.com/LucianoPAlmeida) merged [a pull request](https://github.com/apple/swift/pull/36076) that implements a rule on ranking where overload choices that have `@autoclosure` parameters are disfavored over the ones that aren't to avoid ambiguity and resolves [SR-2705](https://bugs.swift.org/browse/SR-2705).
+
+[Konrad Malawski](https://github.com/ktoso) merged [a pull request](https://github.com/apple/swift/pull/36032) that implements `withCancellationHandler`.
+
+### Accepted proposals
+
+[SE-0301](https://github.com/apple/swift-evolution/blob/main/proposals/0301-package-editing-commands.md): *Package Editor Commands* was [[accepted with modifications](https://forums.swift.org/t/accepted-with-modification-se-0296-async-await/43318](https://forums.swift.org/t/accepted-with-modification-se-0301-package-editor-commands/45069)).
+
+> The feedback from the [pitch](https://forums.swift.org/t/pitch-package-editor-commands/) and [review](https://forums.swift.org/t/se-0301-package-editor-commands/) has been enthusiastically positive and the proposal has been accepted with a few minor revisions:
+>
+> 1.  Change comma delimited arguments to space delimited.
+> 2.  Add `—to` and `—through` flags to `add-dependency` command.
+> 3.  Add information in the "alternatives considered" about alternative command spelling and their tradeoffs.
+
+### Returned proposals
+
+[SE-0293](https://github.com/apple/swift-evolution/blob/main/proposals/0293-extend-property-wrappers-to-function-and-closure-parameters.md) has been [returned for revision](https://forums.swift.org/t/returned-for-revision-2-se-0293-extend-property-wrappers-to-function-and-closure-parameters/44832).
+
+> The improvements from the first draft are significant and addressed all of the concerns from the first round of core team feedback. Community feedback was very positive, including a number of useful discussions and clarifications. While the proposal is very close, the core team would like more exploration of one specific topic: protocol conformance with property wrappers.
+> 
+> The core team feels that property wrappers on functions should compose (somehow) with protocol requirements. The overall model explained in the proposal is that the exposed function type does not have the wrappers on it. One approach would be to be consistent with that where implementations with wrappers on them would fulfill the projected types, an alternate approach would allow fulfilling requirements with the wrapped types. Either way, the core team feels that this should be defined as part of the proposal.
+
+### Proposals in review
+
+[SE-0291](https://github.com/apple/swift-evolution/blob/main/proposals/0300-continuation.md): *Package Collection Signing* is [under a review](https://forums.swift.org/t/amendment-se-0291-package-collection-signing/44887).
+
+> The [amendment](https://github.com/apple/swift-evolution/pull/1270) was requested by the core team to reflect the security model for package collections as discusses in a recent [discussion thread](https://forums.swift.org/t/package-collection-signing/) on the topic. The goal of the amendment is to provide transparency and document that security model.
+
+[SE-0302](https://github.com/apple/swift-evolution/blob/main/proposals/0302-concurrent-value-and-concurrent-closures.md): *ConcurrentValue and `@concurrent` closures* is [under a review](https://forums.swift.org/t/se-0302-concurrentvalue-and-concurrent-closures/44919).
+
+> The [Swift Concurrency Roadmap](https://forums.swift.org/t/swift-concurrency-roadmap/41611/) was recently announced, and a key goal of that roadmap is to “provide a mechanism for isolating state in concurrent programs to eliminate data races.”  Such a mechanism will be a major progression for widely used programming languages — most of them provide concurrent programming abstractions in a way that subjects programmers to a wide range of bugs, including race conditions, deadlocks and other problems.
+>
+> This proposal describes an approach to address one of the challenging problems in this space — how to type check value passing between structured concurrency constructs and actors messages. As such, this is a unifying theory that provides some of the underlying type system mechanics that make them both safe and work well together.
+>
+> This implementation approach involves marker protocols named `ConcurrentValue` and `UnsafeConcurrentValue`, as well as a `@concurrent` attribute that may be applied to functions.
+
+### Swift Forums
+
+[Zoe Carver](https://forums.swift.org/u/zoecarver) [updated](https://forums.swift.org/t/a-short-term-roadmap-for-c-interop/44768) the short-term roadmap for C++ interop.
+
+> My primary goal over the next few months will be to fully import libc++ headers, LLVM headers, and Swift headers without crashing. This doesn't mean we'll necessarily be able to use any of these APIs, just that we'll be able to load the headers without crashing or having other errors. Ideally, we won't regress in terms of what C++ programs we can accept.
+>
+> This should be mostly compiler bug fixes. However, there will be some larger projects, such as making all the headers we plan to use self-contained.
+
+[Holly Borla](https://twitter.com/hollyborla) [informed](https://forums.swift.org/t/pitch-4-se-0293-extend-property-wrappers-to-function-and-closure-parameters/44858) us about updates to [SE-0293](https://github.com/hborla/swift-evolution/blob/se-0293-revision-3/proposals/0293-extend-property-wrappers-to-function-and-closure-parameters.md).
+
+> * The distinction between property wrappers that are API and property wrappers that are implementation detail is formalized via the `api` option in the `@propertyWrapper` attribute, i.e. `@propertyWrapper(api)`
+> * Implementation-detail property wrappers on parameters are sugar for a local wrapped variable.
+> * API-level property wrappers on parameters use caller-side application of the property wrapper. The design of API-level property wrappers attached to parameters is the same as the previous revision of SE-0293.
+> * Overload resolution for property wrapper initializers will always be done at the property wrapper declaration.
+
+[Slava Pestov](https://twitter.com/slava_pestov) pitched [a proposal](https://forums.swift.org/t/pitch-fix-rethrows-checking-and-add-rethrows-unsafe/44863) that fixes a soundness hole in `rethrows` checking, and introduces a new `rethrows(unsafe)` escape hatch for situations where a function has the correct behavior at runtime, but the compiler is unable to prove that this is the case.
+
+[Anders Bertelrud](https://forums.swift.org/u/abertelrud) pitched [a proposal](https://forums.swift.org/t/pitch-swiftpm-extensible-build-tools/44715) to add SwiftPM Extensible build tools.
+
+> Because extensibility is a broad topic and there are a wide variety of needs, this proposal takes the approach of:
+> 
+> 1. Providing a way for packages to implement extensions and letting them define the capabilities of those extensions
+> 2. Providing a way for packages to vend extensions to other packages (or choose to keep them as a private implementation detail of the package)
+> 3. Providing an initial set of extension capabilities that is narrowly focused on source generation and analysis, which seems to be one of the most common needs today
+
+[Johannes Weiss](https://twitter.com/johannesweiss/) shared Swift on the Server Workgroup [January 6, 2021 meeting notes](https://forums.swift.org/t/january-6-2021/44908).
+
+[Xiaodi Wu](https://forums.swift.org/u/xwu) pitched [a proposal](https://forums.swift.org/t/exponentiation-operator-and-precedence-group/44895) to add an exponentiation operator and precedence group.
+
+> We propose the addition of `**` as the exponentiation operator, assigned to a precedence group named `ExponentiationPrecedence` that is higher than `MultiplicationPrecedence`.
+
+[Tim Condon](https://twitter.com/0xTim) shared news from the Vapor team that they are [renaming the default branch](https://forums.swift.org/t/vapor-branch-renaming/45017) and an update describing how they [found and fixed](https://forums.swift.org/t/vapor-4-40-1-denial-of-service-vulnerability-in-the-metrics-integration/44985) a vulnerability in Vapor's Swift Metrics integration.
+
+[Holly Borla](https://twitter.com/hollyborla) informed us that [Filip Sakel](https://forums.swift.org/u/filip-sakel) has revised the design of SE-0293 again, and the latest proposal draft is available [here](https://github.com/hborla/swift-evolution/blob/se-0293-revision-3/proposals/0293-extend-property-wrappers-to-function-and-closure-parameters.md).
+
+> Here is a list of changes to the design in this revision (compared to the last reviewed version):
+>
+> * The distinction between API wrappers and implementation-detail wrappers is formalized, and determined by the compiler based on whether the property wrapper type allows the call-site to pass a different type of argument.
+> * Implementation-detail property wrappers on parameters are sugar for a local wrapped variable.
+> * API property wrappers on parameters use caller-side application of the property wrapper.
+> * Overload resolution for property wrapper initializers will always be done at the property wrapper declaration to minimize the semantic differences between the two property wrapper models.
+
+### Finally
+
+* [`then`](https://twitter.com/jckarter/status/1359983768488955904)
+* [souiphte](https://twitter.com/gregheo/status/1361589553463664640)

new_draft.sh

@@ -62,7 +62,7 @@ sponsor:
 
 ### Starter tasks
 
-> TODO
+> TODO - [SR-](https://bugs.swift.org/browse/SR-) [] 
 
 ### Podcasts