diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml
index 5b6f41f0..ace64de2 100644
--- a/.github/workflows/ci.yml
+++ b/.github/workflows/ci.yml
@@ -16,7 +16,7 @@ jobs:
runs-on: macOS-latest
steps:
- name: git checkout
- uses: actions/checkout@v2.3.4
+ uses: actions/checkout@v2.4.0
- name: versions
run: |
@@ -25,7 +25,7 @@ jobs:
bundler --version
- name: cache
- uses: actions/cache@v2.1.5
+ uses: actions/cache@v3.0.2
with:
path: vendor/bundle
key: ${{ runner.os }}-gem-${{ hashFiles('**/Gemfile.lock') }}
diff --git a/.ruby-version b/.ruby-version
new file mode 100644
index 00000000..fd2a0186
--- /dev/null
+++ b/.ruby-version
@@ -0,0 +1 @@
+3.1.0
diff --git a/CNAME b/CNAME
deleted file mode 100644
index 31841c86..00000000
--- a/CNAME
+++ /dev/null
@@ -1 +0,0 @@
-swiftweeklybrief.com
\ No newline at end of file
diff --git a/Gemfile b/Gemfile
index 694223a8..c8457296 100644
--- a/Gemfile
+++ b/Gemfile
@@ -12,3 +12,5 @@ gem 'danger-prose'
gem 'claide'
gem 'octokit'
gem 'colorize'
+
+gem "webrick", "~> 1.7"
diff --git a/Gemfile.lock b/Gemfile.lock
index 363bccd1..ffe448b9 100644
--- a/Gemfile.lock
+++ b/Gemfile.lock
@@ -1,15 +1,14 @@
GEM
remote: https://rubygems.org/
specs:
- activesupport (6.0.4.1)
+ activesupport (7.0.4.3)
concurrent-ruby (~> 1.0, >= 1.0.2)
- i18n (>= 0.7, < 2)
- minitest (~> 5.1)
- tzinfo (~> 1.1)
- zeitwerk (~> 2.2, >= 2.2.2)
- addressable (2.8.0)
- public_suffix (>= 2.0.2, < 5.0)
- claide (1.0.3)
+ i18n (>= 1.6, < 2)
+ minitest (>= 5.1)
+ tzinfo (~> 2.0)
+ addressable (2.8.1)
+ public_suffix (>= 2.0.2, < 6.0)
+ claide (1.1.0)
claide-plugins (0.9.2)
cork
nap
@@ -21,12 +20,11 @@ GEM
colorator (1.1.0)
colored2 (3.1.2)
colorize (0.8.1)
- commonmarker (0.17.13)
- ruby-enum (~> 0.5)
- concurrent-ruby (1.1.9)
+ commonmarker (0.23.8)
+ concurrent-ruby (1.2.2)
cork (0.3.0)
colored2 (~> 3.1)
- danger (8.3.1)
+ danger (8.6.1)
claide (~> 1.0)
claide-plugins (>= 0.9.2)
colored2 (~> 3.1)
@@ -41,51 +39,57 @@ GEM
terminal-table (>= 1, < 4)
danger-prose (2.0.7)
danger
- dnsruby (1.61.7)
+ dnsruby (1.61.9)
simpleidn (~> 0.1)
- em-websocket (0.5.2)
+ em-websocket (0.5.3)
eventmachine (>= 0.12.9)
- http_parser.rb (~> 0.6.0)
- ethon (0.14.0)
+ http_parser.rb (~> 0)
+ ethon (0.16.0)
ffi (>= 1.15.0)
eventmachine (1.2.7)
execjs (2.8.1)
- faraday (1.8.0)
+ faraday (1.10.3)
faraday-em_http (~> 1.0)
faraday-em_synchrony (~> 1.0)
faraday-excon (~> 1.1)
- faraday-httpclient (~> 1.0.1)
+ faraday-httpclient (~> 1.0)
+ faraday-multipart (~> 1.0)
faraday-net_http (~> 1.0)
- faraday-net_http_persistent (~> 1.1)
+ faraday-net_http_persistent (~> 1.0)
faraday-patron (~> 1.0)
faraday-rack (~> 1.0)
- multipart-post (>= 1.2, < 3)
+ faraday-retry (~> 1.0)
ruby2_keywords (>= 0.0.4)
faraday-em_http (1.0.0)
faraday-em_synchrony (1.0.0)
faraday-excon (1.1.0)
- faraday-http-cache (2.2.0)
+ faraday-http-cache (2.4.1)
faraday (>= 0.8)
faraday-httpclient (1.0.1)
+ faraday-multipart (1.0.4)
+ multipart-post (~> 2)
faraday-net_http (1.0.1)
faraday-net_http_persistent (1.2.0)
faraday-patron (1.0.0)
faraday-rack (1.0.0)
- ffi (1.15.4)
+ faraday-retry (1.0.3)
+ ffi (1.15.5)
forwardable-extended (2.6.0)
gemoji (3.0.1)
- git (1.9.1)
+ git (1.18.0)
+ addressable (~> 2.8)
rchardet (~> 1.8)
- github-pages (219)
- github-pages-health-check (= 1.17.7)
- jekyll (= 3.9.0)
+ github-pages (228)
+ github-pages-health-check (= 1.17.9)
+ jekyll (= 3.9.3)
jekyll-avatar (= 0.7.0)
jekyll-coffeescript (= 1.1.1)
- jekyll-commonmark-ghpages (= 0.1.6)
+ jekyll-commonmark-ghpages (= 0.4.0)
jekyll-default-layout (= 0.1.4)
jekyll-feed (= 0.15.1)
jekyll-gist (= 1.5.0)
jekyll-github-metadata (= 2.13.0)
+ jekyll-include-cache (= 0.2.1)
jekyll-mentions (= 1.6.0)
jekyll-optional-front-matter (= 0.3.2)
jekyll-paginate (= 1.1.0)
@@ -94,7 +98,7 @@ GEM
jekyll-relative-links (= 0.6.1)
jekyll-remote-theme (= 0.4.3)
jekyll-sass-converter (= 1.5.2)
- jekyll-seo-tag (= 2.7.1)
+ jekyll-seo-tag (= 2.8.0)
jekyll-sitemap (= 1.4.0)
jekyll-swiss (= 1.0.0)
jekyll-theme-architect (= 0.2.0)
@@ -112,31 +116,31 @@ GEM
jekyll-theme-time-machine (= 0.2.0)
jekyll-titles-from-headings (= 0.5.3)
jemoji (= 0.12.0)
- kramdown (= 2.3.1)
+ kramdown (= 2.3.2)
kramdown-parser-gfm (= 1.1.0)
- liquid (= 4.0.3)
+ liquid (= 4.0.4)
mercenary (~> 0.3)
minima (= 2.5.1)
- nokogiri (>= 1.10.4, < 2.0)
+ nokogiri (>= 1.13.6, < 2.0)
rouge (= 3.26.0)
terminal-table (~> 1.4)
- github-pages-health-check (1.17.7)
+ github-pages-health-check (1.17.9)
addressable (~> 2.3)
dnsruby (~> 1.60)
octokit (~> 4.0)
public_suffix (>= 3.0, < 5.0)
typhoeus (~> 1.3)
- html-pipeline (2.14.0)
+ html-pipeline (2.14.3)
activesupport (>= 2)
nokogiri (>= 1.4)
- http_parser.rb (0.6.0)
- i18n (0.9.5)
+ http_parser.rb (0.8.0)
+ i18n (1.12.0)
concurrent-ruby (~> 1.0)
- jekyll (3.9.0)
+ jekyll (3.9.3)
addressable (~> 2.4)
colorator (~> 1.0)
em-websocket (~> 0.5)
- i18n (~> 0.7)
+ i18n (>= 0.7, < 2)
jekyll-sass-converter (~> 1.0)
jekyll-watch (~> 2.0)
kramdown (>= 1.17, < 3)
@@ -150,13 +154,13 @@ GEM
jekyll-coffeescript (1.1.1)
coffee-script (~> 2.2)
coffee-script-source (~> 1.11.1)
- jekyll-commonmark (1.3.1)
- commonmarker (~> 0.14)
- jekyll (>= 3.7, < 5.0)
- jekyll-commonmark-ghpages (0.1.6)
- commonmarker (~> 0.17.6)
- jekyll-commonmark (~> 1.2)
- rouge (>= 2.0, < 4.0)
+ jekyll-commonmark (1.4.0)
+ commonmarker (~> 0.22)
+ jekyll-commonmark-ghpages (0.4.0)
+ commonmarker (~> 0.23.7)
+ jekyll (~> 3.9.0)
+ jekyll-commonmark (~> 1.4.0)
+ rouge (>= 2.0, < 5.0)
jekyll-default-layout (0.1.4)
jekyll (~> 3.0)
jekyll-feed (0.15.1)
@@ -166,6 +170,8 @@ GEM
jekyll-github-metadata (2.13.0)
jekyll (>= 3.4, < 5.0)
octokit (~> 4.0, != 4.4.0)
+ jekyll-include-cache (0.2.1)
+ jekyll (>= 3.7, < 5.0)
jekyll-mentions (1.6.0)
html-pipeline (~> 2.3)
jekyll (>= 3.7, < 5.0)
@@ -185,7 +191,7 @@ GEM
rubyzip (>= 1.3.0, < 3.0)
jekyll-sass-converter (1.5.2)
sass (~> 3.4)
- jekyll-seo-tag (2.7.1)
+ jekyll-seo-tag (2.8.0)
jekyll (>= 3.8, < 5.0)
jekyll-sitemap (1.4.0)
jekyll (>= 3.7, < 5.0)
@@ -238,45 +244,45 @@ GEM
gemoji (~> 3.0)
html-pipeline (~> 2.2)
jekyll (>= 3.0, < 5.0)
- kramdown (2.3.1)
+ kramdown (2.3.2)
rexml
kramdown-parser-gfm (1.1.0)
kramdown (~> 2.0)
- liquid (4.0.3)
- listen (3.7.0)
+ liquid (4.0.4)
+ listen (3.8.0)
rb-fsevent (~> 0.10, >= 0.10.3)
rb-inotify (~> 0.9, >= 0.9.10)
mercenary (0.3.6)
- mini_portile2 (2.6.1)
+ mini_portile2 (2.8.1)
minima (2.5.1)
jekyll (>= 3.5, < 5.0)
jekyll-feed (~> 0.9)
jekyll-seo-tag (~> 2.1)
- minitest (5.14.4)
- multipart-post (2.1.1)
+ minitest (5.18.0)
+ multipart-post (2.3.0)
nap (1.1.0)
no_proxy_fix (0.1.2)
- nokogiri (1.12.5)
- mini_portile2 (~> 2.6.1)
+ nokogiri (1.14.2)
+ mini_portile2 (~> 2.8.0)
+ racc (~> 1.4)
+ nokogiri (1.14.2-arm64-darwin)
racc (~> 1.4)
- nokogiri (1.12.5-x86_64-darwin)
+ nokogiri (1.14.2-x86_64-darwin)
racc (~> 1.4)
- octokit (4.21.0)
- faraday (>= 0.9)
- sawyer (~> 0.8.0, >= 0.5.3)
+ octokit (4.25.1)
+ faraday (>= 1, < 3)
+ sawyer (~> 0.9)
open4 (1.3.4)
pathutil (0.16.2)
forwardable-extended (~> 2.6)
- public_suffix (4.0.6)
- racc (1.5.2)
- rb-fsevent (0.11.0)
+ public_suffix (4.0.7)
+ racc (1.6.2)
+ rb-fsevent (0.11.2)
rb-inotify (0.10.1)
ffi (~> 1.0)
rchardet (1.8.0)
rexml (3.2.5)
rouge (3.26.0)
- ruby-enum (0.9.0)
- i18n
ruby2_keywords (0.0.5)
rubyzip (2.3.2)
safe_yaml (1.0.5)
@@ -285,23 +291,22 @@ GEM
sass-listen (4.0.0)
rb-fsevent (~> 0.9, >= 0.9.4)
rb-inotify (~> 0.9, >= 0.9.7)
- sawyer (0.8.2)
+ sawyer (0.9.2)
addressable (>= 2.3.5)
- faraday (> 0.8, < 2.0)
+ faraday (>= 0.17.3, < 3)
simpleidn (0.2.1)
unf (~> 0.1.4)
terminal-table (1.8.0)
unicode-display_width (~> 1.1, >= 1.1.1)
- thread_safe (0.3.6)
typhoeus (1.4.0)
ethon (>= 0.9.0)
- tzinfo (1.2.9)
- thread_safe (~> 0.1)
+ tzinfo (2.0.6)
+ concurrent-ruby (~> 1.0)
unf (0.1.4)
unf_ext
- unf_ext (0.0.8)
+ unf_ext (0.0.8.2)
unicode-display_width (1.8.0)
- zeitwerk (2.4.2)
+ webrick (1.8.1)
PLATFORMS
ruby
@@ -319,6 +324,7 @@ DEPENDENCIES
jekyll-paginate
jekyll-sitemap
octokit
+ webrick (~> 1.7)
BUNDLED WITH
- 2.2.23
+ 2.4.9
diff --git a/_includes/footer.html b/_includes/footer.html
index 5bcaead6..3c60377e 100644
--- a/_includes/footer.html
+++ b/_includes/footer.html
@@ -26,7 +26,6 @@
-
diff --git a/_includes/header.html b/_includes/header.html
index 6507d978..b1143674 100644
--- a/_includes/header.html
+++ b/_includes/header.html
@@ -3,23 +3,12 @@
diff --git a/_includes/subscribe.html b/_includes/subscribe.html
index 1be143a7..e0f8d231 100644
--- a/_includes/subscribe.html
+++ b/_includes/subscribe.html
@@ -2,10 +2,9 @@
diff --git a/_posts/2021-09-23-issue-194.md b/_posts/2021-09-23-issue-194.md
index bf8ba153..61db5f74 100644
--- a/_posts/2021-09-23-issue-194.md
+++ b/_posts/2021-09-23-issue-194.md
@@ -6,7 +6,7 @@ author: fassko
How many of you have pre-ordered the new iPhone 13? Tomorrow is the big day, when we can see the new device hit the store shelves. Apple claims that the new iPhone has a brand new dual-camera system, a super-fast A15 chip and a massive leap in battery life.
-But we are here not only for the new and pretty iPhone colors – Xcode 13.0 was released just a couple of days ago along with [Swift 5.5](https://forums.swift.org/t/swift-5-5-released/52247). Here's a listing of Swift 5.5 [updates](https://twitter.com/simjp/status/1440318174856036354). This is a big release, and it includes quite a few new features. The iOS 13.0 release notes can be found here: [iOS 15](https://developer.apple.com/documentation/ios-ipados-release-notes/ios-ipados-15-release-notes). And the work to [back-deploy concurrency features](https://github.com/apple/swift/pull/39342) to older Swift versions has begun.
+But we are here not only for the new and pretty iPhone colors – Xcode 13.0 was released just a couple of days ago along with [Swift 5.5](https://forums.swift.org/t/swift-5-5-released/52247). Here's a listing of Swift 5.5 [updates](https://twitter.com/simjp/status/1440318174856036354). This is a big release, and it includes quite a few new features. The iOS 13.0 release notes can be found [here](https://developer.apple.com/documentation/ios-ipados-release-notes/ios-ipados-15-release-notes). And the work to [back-deploy concurrency features](https://github.com/apple/swift/pull/39342) to older Swift versions has begun.
To keep running this project and send you this newsletter, we are inviting sponsors to reach out. Your support is very much appreciated and helps us cover the platform costs.
diff --git a/_posts/2021-10-07-issue-195.md b/_posts/2021-10-07-issue-195.md
new file mode 100644
index 00000000..80e4b1d6
--- /dev/null
+++ b/_posts/2021-10-07-issue-195.md
@@ -0,0 +1,124 @@
+---
+layout: post
+title: ! 'Issue #195'
+author: fassko
+sponsor:
+ link: https://iosacademy.essentialdeveloper.com/p/ios-architect-crash-course-swbe1c9/
+ heading: Free Course for Mid to Senior iOS Developers
+ body: From October 18th to 24th you can join a free practical crash course for iOS devs who want to become complete senior developers.
+ displaylink: iosacademy.essentialdeveloper.com
+---
+
+We're starting today’s newsletter with some hiring news from Apple: they are [looking for paid interns](https://twitter.com/jckarter/status/1441445811523502088) for their language, compiler and debugger teams. Even if you don't have experience in the specific field, interested students are encouraged to apply anyway. If you’d like to understand better how internships work, have a look at [this](https://forums.swift.org/t/swift-mentorship-compiler-language-design/52522) insightful article about [Amritpan Kaur's](https://twitter.com/Amritpan) path through Compiler Development and Language Design.
+
+There have been some really nice improvements made to Swift.org recently, including [support for dark mode](https://forums.swift.org/t/swift-org-in-dark-mode/52495). For those of you using dark mode on iOS, the website will automatically switch modes to match. I hope you’re enjoying this feature as much as I am.
+
+As always, I want to express our appreciation for the support from our sponsors. Without you this newsletter wouldn't exist, so thank you very much. If anyone else is interested in sponsorship, please kindly get in touch. More information on how you could participate in our project can be found [here](https://swiftweeklybrief.com/sponsorship/).
+
+
+
+{% include sponsor.html %}
+
+### Starter tasks
+
+> [SR-15271](https://bugs.swift.org/browse/SR-15271) [Compiler] Improve Codable Diagnostics When `CodingKeys` Do Not Match Properties
+
+### News and community
+
+[Ted Kremenek](https://twitter.com/tkremenek) wrote [a post](https://swift.org/blog/swift-5-5-released/) about the Swift 5.5 release.
+
+[Bruno Rocha](https://twitter.com/rockbruno_) published [a great article](https://swiftrocks.com/how-asyncsequence-works-internally-in-swift) explaining how `AsyncSequence` works internally in Swift.
+
+[Lee Kah Seng](https://twitter.com/Lee_Kah_Seng) wrote [a cool article](https://swiftsenpai.com/swift/actor-reentrancy-problem/) describing the actor reentrancy problem in Swift.
+
+[Amritpan Kaur](https://twitter.com/Amritpan) [explained](https://forums.swift.org/t/swift-mentorship-compiler-language-design/52522) how she participated in the inaugural Swift Mentorship and worked on Compiler Development and Language Design.
+
+### Commits and pull requests
+
+[Michael Ilseman](https://github.com/milseman) merged [a pull request](https://github.com/apple/swift/pull/38922) that implements native normalization for String.
+
+[Doug Gregor](https://twitter.com/dgregor79) created [a pull request](https://github.com/apple/swift/pull/39609) that would back-deploy `@objc` actor types.
+
+### Accepted proposals
+
+[SE-0322](https://github.com/apple/swift-evolution/blob/main/proposals/0322-temporary-buffers.md) *Temporary Uninitialized Buffers* was [accepted with modifications](https://forums.swift.org/t/accepted-with-modifications-se-0322-temporary-uninitialized-buffers/52532).
+
+[SE-0323](https://github.com/apple/swift-evolution/blob/main/proposals/0323-async-main-semantics.md) *Asynchronous Main Semantics* was [accepted](https://forums.swift.org/t/accepted-se-0323-asynchronous-main-semantics/52531).
+
+[SE-0324](https://github.com/apple/swift-evolution/blob/main/proposals/0324-c-lang-pointer-arg-conversion.md) *Relax diagnostics for pointer arguments to C functions* was [accepted](https://forums.swift.org/t/accepted-se-0324-relax-diagnostics-for-pointer-arguments-to-c-functions/52599).
+
+### Proposals in review
+
+[SSWG-0017](https://github.com/swift-server/sswg/blob/main/proposals/0017-multipart-kit.md): *MultipartKit* is [under review](https://forums.swift.org/t/sswg-0017-multipartkit/52586).
+
+> MultipartKit offers both low level parsing and serializing of Multipart data as well as high level Codable support for encoding and decoding Multipart form data.
+
+### Swift Forums
+
+[Karoy Lorentey](https://twitter.com/lorentey) [asked](https://forums.swift.org/t/when-should-managedatomic-unsafeatomic-be-marked-sendable/52321) when should `ManagedAtomic`/`UnsafeAtomic` be marked `Sendable`?
+
+> I just filed [issue #45](https://github.com/apple/swift-atomics/issues/45), asking `UnsafeAtomic`, `ManagedAtomic` and friends to be marked `Sendable`, reflecting that they are safe to transfer across concurrency domains.
+
+[Kavon Farvardin](https://twitter.com/call1cc) [proposed](https://forums.swift.org/t/proposal-actor-initializers-and-deinitializers/52322) to define how actor initializers work in Swift.
+
+> The proposed solution to some of the problems described in this proposal are currently reflected in Swift 5.5 through a warning, but it's important to review these changes for Swift 6. In addition, this proposal adds extra capabilities for the `deinit` of MainActor-isolated class, to make them easier and safer to write. I'll paste the entire proposal below, but for the most up-to-date write-up, [go here](https://github.com/kavon/swift-evolution/blob/actor-init-proposal2/proposals/nnnn-actor-initializers.md).
+
+[Kelvin Ma](https://github.com/kelvin13) [discovered](https://forums.swift.org/t/swift-5-5-has-serious-stack-corruption-bugs/52344) that Swift 5.5 has serious stack corruption bugs.
+
+> I’ve discovered several stack corruption bugs related to `async`/`await` which can be reproduced in simple test programs compiled with recent nightly toolchains. **i have confirmed that ~~two~~ ~~three~~ four of these bugs are present in the 5.5-RELEASE toolchain.**
+
+[Becca Royal-Gordon](https://forums.swift.org/u/beccadax) pitched [a proposal](https://forums.swift.org/t/pitch-2-staging-in-sendable-checking/52413) to add staging in sendable checking.
+
+> A couple weeks ago, [@Douglas_Gregor](https://forums.swift.org/u/douglas_gregor) [pitched some changes which tried to tackle](https://forums.swift.org/t/pitch-staging-in-sendable-checking/51341) some of the problems involved in adopting `Sendable` checking in a module when some of your clients or dependencies may not have updated yet. I had some concerns about how that pitch’s approach might break or hide bugs when modules were eventually updated, as well as with how Objective-C libraries would be able to control the sendability of their types.
+
+[YR Chen](https://forums.swift.org/u/stevapple) started [a discussion](https://forums.swift.org/t/upon-swift-6-solve-inconsistency-within-the-language/52437) around solving inconsistencies with the release of Swift 6.
+
+> The arrival of Swift 6 means a chance for “regretting” some language designs with API breakage — after 3 years which is fairly a long time for Swift and the Swift community. With the Swift 3.2 and Swift 4.2 effort, transition to a breaking Swift release has proved to be a lot smoother.
+>
+> I would suggest we pick up some of the deferred breaking pitches, which intended to eliminate inconsistency within the language. These ideas have already received positive feedbacks from the community, and yet didn’t make their ways into reality.
+
+[Philippe Hausler](https://forums.swift.org/u/philippe_hausler) pitched [a proposal](https://forums.swift.org/t/pitch-clock-instant-date-and-duration/52451) to define `Clock`, `Instant`, `Date`, and `Duration`.
+
+> The concepts of time can be broken down into three distinct parts: an item to provide a concept of now plus a way to wake up after a given point in time, a concept of a point in time, and a concept of a measurement in time. These three items are respectively a clock, an instant and a duration. The measurement of time can be used for many types of APIs, all the way from the high levels of a concept of a timeout on a network connection, to the amount of time to sleep a task. Currently the APIs that take measurement of time types take `NSTimeInterval` aka `TimeInterval`, `DispatchTimeInterval`, and even types like `timespec`.
+
+[Michael Ilseman](https://twitter.com/Ilseman) pitched [an idea](https://forums.swift.org/t/declarative-string-processing-overview/52459) to implement declarative string processing APIs.
+
+> String processing is hard and the current affordances provided by the Swift Standard Library are underpowered. We propose adding two new _declarative_ string processing APIs—a familiar `Regex` literal and a more powerful `Pattern` result builder—to help make Swift string processing fast and easy.
+>
+> This is a large feature that will ultimately be divided into multiple Swift Evolution proposals. This initial pitch is intended to prompt discussion about the high level direction and to introduce the key prongs of the feature and their relationship to one another.
+
+[Kelvin Ma](https://github.com/kelvin13) started [a discussion](https://forums.swift.org/t/we-need-long-term-support-lts-releases/52462) around long-term-support (“LTS”) releases.
+
+> for those who don’t follow the [Development](https://forums.swift.org/c/development) topic, [@mickeyl](https://forums.swift.org/u/mickeyl), [@timdecode](https://forums.swift.org/u/timdecode), and i have recently [uncovered an alarming number of highly dangerous stack corruption bugs](https://forums.swift.org/t/swift-5-5-has-serious-stack-corruption-bugs/52344) in the Swift 5.5 release toolchain.
+>
+> setting aside the technical aspects of the stack corruption issues in Swift 5.5, which are detailed in the [corresponding thread](https://forums.swift.org/t/swift-5-5-has-serious-stack-corruption-bugs/52344), i would like to kickoff discussions on whether it would be valuable for us to adopt some form of the concept of a [“Long-Term Support” (LTS) release 8](https://en.wikipedia.org/wiki/Long-term_support) in our release cycle, much like Ubuntu has been doing for some time.
+
+[Anders Bertelrud](https://forums.swift.org/u/abertelrud) pitched [a proposal](https://forums.swift.org/t/pitch-additional-api-available-to-swiftpm-plugins/52494) to extend the plugin SwiftPM plugin API to provide more context.
+
+> SE-0303 introduced SwiftPM plugins, focusing in particular on build tool plugins (especially those that generate source code). To keep that proposal bounded, the type and amount of information available to a plugin was geared toward the task of generating build commands.
+>
+> Before starting to consider new kinds of plugins, it seems prudent to expand the information available to plugins of all kinds. Future proposals might add specific APIs for particular kinds of plugins, but before that, it seems that a good starting point would be to give all plugins access to a distilled form of the package graph that SwiftPM already has internally. This should allow a wide latitude in terms of what any particular plugin wants to do.
+>
+> I'd like to pitch a draft proposal for extending the API available to SwiftPM plugins, and would love to hear what everyone thinks. There's an implementation in a PR in the SwiftPM repository.
+
+Guillaume Lessard pitched [a proposal](https://forums.swift.org/t/pitch-expand-usability-of-withmemoryrebound/52500) to expand usability of `withMemoryRebound`.
+
+> The function `withMemoryRebound(to:capacity:_ body:)` executes a closure while temporarily binding a range of memory to a different type than the callee is bound to.
+>
+>We propose to lift some notable limitations of `withMemoryRebound` and enable rebinding to a larger set of types, as well as rebinding from raw memory pointers and buffers.
+
+[Tim Condon](https://twitter.com/0xTim) [updated](https://forums.swift.org/t/async-await-and-the-future-of-vapor/52590) us about `async/await` and the future of Vapor.
+
+[Drew McCormack](https://forums.swift.org/u/drewmccormack) pitched [a proposal](https://forums.swift.org/t/proposal-a-standard-library-type-for-working-with-shared-data-in-a-concurrent-system/52603) that would create standard library data structures designed for working with shared data in a concurrent system.
+
+> I want to propose such a type here: a branching resource.
+>
+> A BranchingResource would be a type with a generic parameter for the payload it carries (ie the resource). The resource would begin with a single branch, called "main" or "trunk" or "truth". The app could add as many auxiliary, named branches as it likes.
+
+[Pavel Yaskevich](https://twitter.com/pyaskevich) pitched [an idea](https://forums.swift.org/t/pitch-enable-multi-statement-closure-parameter-result-type-inference/52619) to enable multi-statement closure parameter/result type inference.
+
+> I propose to improve inference behavior of multi-statement closures by enabling parameter and result type inference from the closure body. This will make type inference less surprising for developers, and remove the existing behavior cliff where adding one more expression or statement to a closure could result in a compilation failure.
+
+### Finally
+
+[typedef unsigned char BOO_L; // 👻](https://twitter.com/jckarter/status/1444003858468855816)
diff --git a/_posts/2021-10-21-issue-196.md b/_posts/2021-10-21-issue-196.md
new file mode 100644
index 00000000..caf3a48b
--- /dev/null
+++ b/_posts/2021-10-21-issue-196.md
@@ -0,0 +1,90 @@
+---
+layout: post
+title: ! 'Issue #196'
+author: fassko
+---
+
+Let me start with some very exciting news - our Swift Weekly Brief has been translated into the Chinese language. You can explore translations [here](https://github.com/SwiftCommunityRes/SwiftWeekly). I am thrilled to share this with all of you as I truly believe that reaching more people from around the world who can make an impressive contribution to our community is our way to broaden horizons leading to new inventions.
+
+Meanwhile, Apple hosted its ‘Unleashed’ event and announced some new impressive hardware, satisfying everyone’s taste. Kids will soon be asking Santa for new AirPods and a colorful HomePod Mini to put under Christmas trees later this year, and professional artists are enthusiastic about new powerful MacBook Pros with Apple’s new chips, either the M1 Pro or M1 Max, with four-wheel-drive versions of the M1 chip they presented last fall. Let me know your thoughts about these new machines. Personally, I am looking forward to the 14-inch desktop as it perfectly fits my needs.
+
+Just a kind reminder that we have various opportunities for sponsorship to help us run this project. You can always find more info about the options [here](https://swiftweeklybrief.com/sponsorship/). Also, I would like to give a shout-out to our current sponsors - we are grateful and appreciate your support.
+
+
+
+{% include sponsor.html %}
+
+### Starter tasks
+
+[SR-15312](https://bugs.swift.org/browse/SR-15312) [Swift-DocC] Add 'version' command to docc command line tool
+
+[SR-15313](https://bugs.swift.org/browse/SR-15313) [Swift-DocC] Primary tutorial navigation dropdown fails to bold the current tutorial when browser URL is not lowercased
+
+### News and community
+
+[Franklin Schrans](http://twitter.com/franklinschrans) [announced](https://swift.org/blog/swift-docc/) [Swift-DocC](https://forums.swift.org/t/announcing-swift-docc/52797) will be [open sourced](https://github.com/apple/swift-docc).
+
+[Marin Todorov](https://twitter.com/icanzilb) finally [revealed](https://twitter.com/icanzilb/status/1448555769050304512) his work on [Swift Markdown](https://github.com/apple/swift-markdown).
+
+[Federico Zanetello](https://twitter.com/zntfdr) wrote [a blog post](https://www.fivestars.blog/articles/warn_unqualified_access/) explaining `@warn_unqualified_access`.
+
+[Dave DeLong](https://twitter.com/davedelong) explained [how](https://davedelong.com/blog/2021/10/09/simplifying-backwards-compatibility-in-swift/) to simplify backwards compatibility in Swift.
+
+Documentation for Swift-DocC is now on [Swift.org](https://swift.org/documentation/docc/) ([using Swift-DocC!](https://forums.swift.org/t/documentation-for-swift-docc-is-now-on-swift-org/52914)).
+
+### Proposals in review
+
+[SE-0325](https://github.com/apple/swift-evolution/blob/main/proposals/0325-swiftpm-additional-plugin-apis.md): *Additional Package Plugin APIs* is [under review](https://forums.swift.org/t/se-0325-additional-package-plugin-apis/52788).
+
+> SE-0303 introduced the ability to define _build tool plugins_ in SwiftPM, allowing custom tools to be invoked while building a package. In support of this, SE-0303 introduced a minimal initial API through which plugins can access information about the target for which they are invoked.
+>
+> This proposal extends the plugin API to provide more context, including a richer representation of the package graph. This is in preparation for supporting new kinds of plugins in the future.
+
+### Swift Forums
+
+[Nuri Amari](https://forums.swift.org/u/nuriamari) pitched [a proposal](https://forums.swift.org/t/pitch-improved-clangimporter-diagnostics/52687) to improve `ClangImporter` diagnostics.
+
+> We would like to propose improvements to the ClangImporter to provide more detailed diagnostics when an entity cannot be imported from C or Objective-C. As it stands, when the ClangImporter fails to import an entity (function, type, macro, etc.) either entirely or partially, failure is largely silent. The current Swift compilation errors present largely as if the entity was never defined at all.
+
+[Frederick Kellison-Linn](https://forums.swift.org/u/jumhyn) pitched [an idea](https://forums.swift.org/t/pitch-generalize-keypath-to-function-conversions/52681) to generalize keypath-to-function conversions.
+
+> This proposal introduces the ability to use the key path expression `\Root.value` wherever functions of `(Root) -> Value` are allowed.
+>
+> Swift-evolution thread: [Key Path Expressions as Functions](https://forums.swift.org/t/key-path-expressions-as-functions/19587)
+
+[Patrick Pijnappel](https://forums.swift.org/u/patrick_pijnappel) pitched [a proposal](https://forums.swift.org/t/pitch-exhaustive-pattern-matching-for-non-open-classes/52718) to implement exhaustive pattern matching for non-open classes.
+
+> Since we now make the distinction between open and non-open classes, it seems we should be able to make non-open class hierarchies exhaustively matchable. This would be a nice win for compile-time checks in the face of adding a new subclass, without any added syntax.
+
+Guillaume Lessard [pitched](https://forums.swift.org/t/pitch-pointer-usability-improvements/52736) improvements to pointer usability.
+
+> This proposal introduces some quality-of-life improvements for `UnsafePointer` and its `Mutable` and `Raw` variants.
+>
+> 1. Add an API to obtain an `UnsafeRawPointer` instance that is advanced to a given alignment from its starting point.
+> 2. Add an API to obtain a pointer to a stored property of an aggregate `T`, given an `UnsafePointer`.
+> 3. Rename the unchecked subscript of `Unsafe[Mutable]Pointer` to include the argument label `unchecked`.
+> 4. Add the ability to compare pointers of any two types.
+
+[Pavel Yaskevich](https://twitter.com/pyaskevich) pitched [a proposal](https://forums.swift.org/t/pitch-light-weight-same-type-constraint-syntax/52889) to improve same-type constraint syntax.
+
+> As a step toward the goal of improving the UI of generics outlined in [Improving the UI of generics](https://forums.swift.org/t/improving-the-ui-of-generics/22814#heading--directly-expressing-constraints), we’d like to propose a couple of improvements that bridge the syntactic gap between protocols and generic types, and hide some of the complexity (both visual and cognitive) of writing same-type constraints on associated types and type parameters of generic types.
+
+[Holly Borla](https://twitter.com/hollyborla) started [a discussion](https://forums.swift.org/t/discussion-easing-the-learning-curve-for-introducing-generic-parameters/52891) about easing the learning curve for introducing generic parameters.
+
+> Swift’s generics system is highly expressive, but understanding the full generality of protocols with associated types, generic signatures with where clauses, and other generics features is a significant barrier to introducing generics into a Swift project. A major goal of a more approachable generics system is easing the learning curve of abstracting a concrete API into a generic one by improving the ergonomics of writing generic code in Swift. This discussion is to solicit feedback on possible directions toward achieving this goal, and gather other ideas surfaced by the community. **Questions, comments, and ideas are all welcome!**
+>
+> Many of the ideas in this post were laid out by [@Joe_Groff](https://forums.swift.org/u/joe_groff) in [Improving the UI of generics](https://forums.swift.org/t/improving-the-ui-of-generics/22814).
+
+[Nate Cook](https://twitter.com/nnnnnnnn) pitched [an idea](https://forums.swift.org/t/pitch-character-classes-for-string-processing/52920) to implement character classes for String processing.
+
+> [Declarative String Processing Overview](https://forums.swift.org/t/declarative-string-processing-overview/52459) presents regex-powered matching broadly, without details concerning syntax and semantics, leaving clarification to subsequent pitches. [Regular Expression Literals](https://forums.swift.org/t/pitch-regular-expression-literals/52820) presents more details on regex _syntax_ such as delimiters and PCRE-syntax innards, but explicitly excludes discussion of regex _semantics_. This pitch and discussion aims to address a targeted subset of regex semantics: definitions of character classes. We propose a comprehensive treatment of regex character class semantics in the context of existing and newly proposed API directly on `Character` and `Unicode.Scalar`.
+>
+> Character classes in regular expressions include metacharacters like `\d` to match a digit, `\s` to match whitespace, and `.` to match any character. Individual literal characters can also be thought of as character classes, as they at least match themselves, and, in case-insensitive matching, their case-toggled counterpart. For the purpose of this work, then, we consider a _character class_ to be any part of a regular expression literal that can match an actual component of a string.
+
+### Finally
+
+[HIG from 1987](https://twitter.com/andy_matuschak/status/1447408339160231947).
+
+[Its pronounced M 1 "ten"](https://twitter.com/pteasima/status/1448634571315195905).
+
+[ Pascal](https://twitter.com/jckarter/status/1448736493590114317).
diff --git a/_posts/2021-11-04-issue-197.md b/_posts/2021-11-04-issue-197.md
new file mode 100644
index 00000000..8a21a735
--- /dev/null
+++ b/_posts/2021-11-04-issue-197.md
@@ -0,0 +1,120 @@
+---
+layout: post
+title: ! 'Issue #197'
+author: fassko
+sponsor:
+ link: https://2021.nsspain.com/
+ heading: NSSpain 2021
+ body: NSSpain 2021 Remote Edition is an online, continuous 36 hours conference, carefully crafted by the community for the community.
+ displaylink: 2021.nsspain.com
+---
+
+How have the last two weeks been for all of you? Personally, I've felt a slight decrease in my working capacity due to lack of daylight and the falling temperatures. By the way, does your country use daylight savings time?
+
+The [Xcode 13.2 Beta](https://developer.apple.com/documentation/xcode-release-notes/xcode-13_2-release-notes#Swift) has concurrency support, which should help to resolve a certain kind of pain-point for many Swift developers. Perhaps the most important benefit of Swift’s built-in concurrency system is that it allows performing multiple asynchronous tasks in parallel in a much easier way. I can only imagine how much time we'll save by speeding up performing tasks.
+
+It is with great pleasure that I write how terrific the last three years of running this newsletter have been. I've met so many incredible people, and thanks to all of you, I have learned so much! This is the reason why typing the following sentence fills me with emotion. Issue 200 will be the last newsletter I run. I have decided to step away from leading this project, and with joyful excitement, I am looking for someone who would like to continue running things.
+
+
+
+{% include sponsor.html %}
+
+### Starter tasks
+
+[SR-15408](https://bugs.swift.org/browse/SR-15408) [Swift-DocC
+] Building documentation with a fallback display name that includes a space produces a broken-looking article
+
+### News and community
+
+New [Xcode 13.2 Beta](https://developer.apple.com/documentation/xcode-release-notes/xcode-13_2-release-notes) adds Swift Concurrency support for macOS 10.15, iOS 13, tvOS 13, and watchOS 6 or newer. This support includes `async/await`, actors, global actors, structured concurrency, and the task APIs.
+
+[Tim Condon](https://twitter.com/0xTim) [posted](https://forums.swift.org/t/async-await-has-arrived-in-vapor/53077) that Vapor now has now `async/await` support.
+
+[Konrad `ktoso` Malawski](https://forums.swift.org/u/ktoso) wrote [a post](https://swift.org/blog/distributed-actors/) introducing Swift Distributed Actors.
+
+[Marc Aupont](https://twitter.com/digimarktech) is [joining](https://forums.swift.org/t/diversity-in-swift-work-group-update/53133) the Diversity in Swift work group.
+
+Swift download links have moved to a new location to provide faster download speeds! The toolchains will be hosted at [download.swift.org](http://download.swift.org/), and it will use a similar pattern as the current URL. To use the new URL, replace `swift.org/builds/` with `download.swift.org/`. Starting Oct 26th 2021, the `swift.org/builds` URLs have been redirected to the new sub domain.
+
+[Sarun Wongpatcharapakorn](https://twitter.com/sarunw) wrote a blog post explaining [KeyPath in Swift](https://sarunw.com/posts/what-is-keypath-in-swift/).
+
+### Commits and pull requests
+
+[Erik Eckstein](https://github.com/eeckstein/) merged [a pull request](https://github.com/apple/swift/pull/39902) that implements a prototype for performance annotations like `@_noLocks` and `@_noAllocation` in Swift.
+
+[Slava Pestov](https://twitter.com/slava_pestov) merged [a pull request](https://github.com/apple/swift/pull/39918) that improves handling of identity conformances `[P].[P] => [P]`.
+
+[John McCall](https://github.com/rjmccall) merged [a pull request](https://github.com/apple/swift/pull/39829) that fixes the alignment of future fragments for highly-aligned result types.
+
+### Accepted proposals
+
+[SE-0325](https://github.com/apple/swift-evolution/blob/main/proposals/0325-swiftpm-additional-plugin-apis.md) *Additional Package Plugin APIs* was [accepted with modifications](https://forums.swift.org/t/accepted-with-modifications-se-0325-additional-package-plugin-apis/53086).
+
+### Proposals in review
+
+[SE-0326](https://github.com/apple/swift-evolution/blob/main/proposals/0326-extending-multi-statement-closure-inference.md): *Multi-statement closure parameter/result type inference* is [under review](https://forums.swift.org/t/se-0326-multi-statement-closure-parameter-result-type-inference/52964).
+
+> I propose to improve inference behavior of multi-statement closures by enabling parameter and result type inference from the closure body. This will make type inference less surprising for developers, and remove the existing behavior cliff where adding one more expression or statement to a closure could result in a compilation failure.
+
+[SE-SE-0327](https://github.com/apple/swift-evolution/blob/main/proposals/0327-actor-initializers.md): *On Actors and Initialization* is [under review](https://forums.swift.org/t/se-0327-on-actors-and-initialization/53053).
+
+> Actors are a relatively new nominal type in Swift that provides data-race safety for its mutable state.
+The protection is achieved by _isolating_ the mutable state of each actor instance to at most one task at a time.
+The proposal that introduced actors ([SE-0306](https://github.com/apple/swift-evolution/blob/main/proposals/0306-actors.md)) is quite large and detailed, but misses some of the subtle aspects of creating and destroying an actor's isolated state.
+This proposal aims to shore up the definition of an actor, to clarify _when_ the isolation of the data begins and ends for an actor instance, along with _what_ can be done inside the body of an actor's `init` and `deinit` declarations.
+
+[SE-0328](https://github.com/apple/swift-evolution/blob/main/proposals/0328-structural-opaque-result-types.md): *Structural opaque result types* is [under review](hhttps://forums.swift.org/t/se-0328-structural-opaque-result-types/53248).
+
+> An [opaque result type](https://github.com/apple/swift-evolution/blob/main/proposals/0244-opaque-result-types.md) may be used as the result type of a function, the type of a variable, or the result type of a subscript. In all cases, the opaque result type must be the entire type. This proposal recommends lifting that restriction and allowing opaque result types in "structural" positions.
+
+### Swift Forums
+
+A little history [lesson](https://forums.swift.org/t/get-folders-number-of-elements/30674/12) from [@justkwin](https://twitter.com/justkwin) about how Foundation ended up using URLs to represent file.paths.
+
+[Anders Bertelrud](https://forums.swift.org/u/abertelrud) pitched [a proposal](https://forums.swift.org/t/pitch-package-manager-command-plugins/53172) to add package manager command plugins.
+
+> [SE-0303](https://github.com/apple/swift-evolution/blob/main/proposals/0303-swiftpm-extensible-build-tools.md) introduced the first kind of SwiftPM plugins, focusing on the ability to extend the build system with custom build tool invocations (in particular for the purpose of generating source code). Those plugins were always intended to be just the first kind of plugin supported by SwiftPM.
+>
+> I'd like to pitch a draft proposal for adding another kind of more general-purpose "command plugin" to SwiftPM. These kinds of plugins would be directly invocable by users and would be intended for such things as source code formatting, documentation generation, test report generation, etc. A command plugin would not necessarily have anything to do with the build system.
+>
+> One important aspect of these custom command plugins is that they can ask the plugin host (either SwiftPM or an IDE that supports packages) to generate specialized information on-demand or to initiate builds or test runs. This is the part of the draft proposal that could use the most scrutiny. There is an element of tension here between making the API rich enough to be as useful as possible, while also making it generic enough to be implementable not only in SwiftPM but also in IDEs that support Swift Packages.
+
+Guillaume Lessard pitched [a proposal](https://forums.swift.org/t/pitch-pointer-family-initialization-improvements/53168) that would implement pointer family initialization improvements.
+
+> The types in the `UnsafeMutablePointer` family typically require manual management of memory allocations, including the management of their initialization state. The states involved are, after allocation:
+>
+> 1. Unbound and uninitialized (as returned from `UnsafeMutableRawPointer.allocate()`)
+> 2. Bound to a type, and uninitialized (as returned from `UnsafeMutablePointer.allocate()`)
+> 3. Bound to a type, and initialized
+>
+> Memory can be safely deallocated whenever it is uninitialized.
+>
+> Unfortunately, not every relevant type in the family has the necessary functionality to fully manage the initialization state of its memory. We intend to address this issue in this proposal, and provide functionality to manage initialization state in a much expanded variety of situations.
+
+[Kelvin Ma](https://github.com/kelvin13) started [a discussion](https://forums.swift.org/t/asyncstream-constructor-which-also-returns-its-continuation/53251) about `AsyncStream` constructor which also returns its Continuation.
+
+> is there any way we can add an API to `AsyncStream` which returns the continuation directly, so we do not have to “juggle” it out of the closure?
+>
+> in general, i also feel like `AsyncStream` is really difficult to work with due to the requirement that iteration happen in the same Task that the `AsyncStream` was created in, even when no concurrent iteration ever takes place. this makes it hard to “subscribe” to events generated from `actor` objects, even when the subscription method is marked `nonisolated`.
+
+Adam Fowler [pitched](https://forums.swift.org/t/mqttnio/53238) the library [MQTTNIO](https://github.com/adam-fowler/mqtt-nio) for inclusion in the SSWG package list.
+
+> MQTT is a messaging protocol commonly used for communicating with IoT (Internet of Things) devices. It is a lightweight publish/subscribe message transport designed to have a small code footprint and network bandwidth.
+
+[Cory Benfield](https://twitter.com/Lukasaoz) [updated](https://forums.swift.org/t/swiftnio-swift-version-support/53232) us about the SwiftNIO Swift version support.
+
+> The SwiftNIO team has made it a major pillar of our workflow to attempt to support Swift releases for a reasonably long time. Most users don't take advantage of this, preferring to stay on the most recent release of Swift, but we think it's important that you have confidence that newly written applications will get some meaningful amount of support going forward.
+
+[Victoria Mitchell](https://twitter.com/QuietMisdreavus) wrote [a post](https://forums.swift.org/t/extending-swift-docc-to-support-objective-c-documentation/53243) about extending Swift-DocC to support Objective-C documentation.
+
+> DocC is currently architected to render symbol documentation in a single language (Swift). However, there are cross-language projects that would benefit from collecting multiple “language variants” together into the same set of documentation, for example for Objective-C APIs that can be called from Swift or vice-versa.
+
+### Finally
+
+[π](https://twitter.com/jckarter/status/1451258136648511488)
+
+[The Iconic Pillow Collection 2](https://twitter.com/throwboy/status/1453739351179816960).
+
+[Infinite energy](https://twitter.com/niw/status/1455258442541711365?s=21).
+
+[Cornelius Dispatch](https://twitter.com/AirspeedSwift/status/1455735695855677447).
diff --git a/_posts/2021-11-18-issue-198.md b/_posts/2021-11-18-issue-198.md
new file mode 100644
index 00000000..c92b3aab
--- /dev/null
+++ b/_posts/2021-11-18-issue-198.md
@@ -0,0 +1,110 @@
+---
+layout: post
+title: ! 'Issue #198'
+author: fassko
+sponsor:
+ link: https://getstream.io/chat/sdk/ios/
+ heading: Build real-time chat messaging in less time with Stream
+ body: Rapidly ship in-app messaging with Stream’s highly reliable chat infrastructure and feature-rich SDKs. Drive in-app conversion, engagement, and retention.
+ displaylink: getstream.io/chat/sdk/ios/
+---
+
+The holiday season is just around the corner. Most of us enjoy Thanksgiving right before Christmas. For others, the festivities start after Christmas and continue even after New Year’s Eve. Despite the differences, we should all enjoy some time off with our families and friends and for this period, merge access will be locked down in Swift. Check out the [holiday schedule](https://forums.swift.org/t/holiday-schedule/53507) and plan your work accordingly.
+
+There is a new feature in [Xcode 13.2 beta](https://developer.apple.com/documentation/xcode-release-notes/xcode-13_2-release-notes#Build-System) which makes build times much faster by using more CPU cores. This new build system is opt-in, so you'll have to enable it.
+
+Before we jump into other detailed news, I would like to express my gratitude to our sponsors who have helped us to run this project for the rest of the year. We would not be here without your support.
+
+
+
+{% include sponsor.html %}
+
+### Podcasts
+
+In [episode 108](https://swiftbysundell.com/podcast/108/) of the Swift by Sundell podcast, [Marin Todorov](https://twitter.com/icanzilb), joins [John Sundell](https://twitter.com/johnsundell). They discuss Swift’s new concurrency system and its newly announced backward compatibility, his new book about that topic, and his work on Apple’s open source documentation tool, [Swift-DocC](https://github.com/apple/swift-docc).
+
+### News and community
+
+[Nicole Jacque](https://twitter.com/racer_girl27) updated us about the [Swift 5.6 release process](https://forums.swift.org/t/swift-5-6-release-process/53412).
+
+[Mishal Shah](https://twitter.com/mishaldshah) [informed](https://forums.swift.org/t/updating-llvm-project-branch-for-swift-main/53438) us about updating llvm-project branch for `swift:main`.
+
+[John Sundell](https://twitter.com/johnsundell) announced [CollectionConcurrencyKit](https://github.com/JohnSundell/CollectionConcurrencyKit) - a lightweight Swift package that adds asynchronous and concurrent versions of the standard `map`, `flatMap`, `compactMap`, and `forEach` APIs to all Swift collections that conform to the `Sequence` protocol.
+He wrote [an article](https://www.swiftbysundell.com/articles/async-and-concurrent-forEach-and-map/) explaining how to build async and concurrent versions of `forEach` and `map`.
+
+[Steven Van Impe](https://twitter.com/pwsacademy) [introduced](https://forums.swift.org/t/introducing-swift-in-higher-education/53445) [Swift in higher education](https://www.pwsacademy.org/).
+
+[Mishal Shah](https://twitter.com/mishaldshah/) informed us about [the Holiday Schedule](https://forums.swift.org/t/holiday-schedule/53507) for Swift projects.
+
+[Leonardo Maia Pugliese](https://twitter.com/Leo_Pugliese) wrote [an article](https://holyswift.app/reverse-reverse-linked-list-linked-list-using-recursion) explaining linked lists using recursion.
+
+[Antoine van der Lee](https://twitter.com/twannl) explained property wrappers in Swift in a [blog post](https://www.avanderlee.com/swift/property-wrappers/).
+
+### Accepted proposals
+
+[SE-0326](https://github.com/apple/swift-evolution/blob/main/proposals/0326-extending-multi-statement-closure-inference.md) *Multi-statement closure parameter/result type inference* was [accepted](https://forums.swift.org/t/accepted-se-0326-multi-statement-closure-parameter-result-type-inference/53502).
+
+### Returned proposals
+
+[SE-0327](https://github.com/apple/swift-evolution/blob/main/proposals/0327-actor-initializers.md) has been [returned for revision](https://forums.swift.org/t/returned-for-revision-se-0327-on-actors-and-initialization/53447).
+
+> The review discussion centered on the complexity of the initialization model, and has uncovered a simpler model that should be easier to reason about. The Core Team has returned this proposal for revision to investigate this new model. Thank you to everyone who participated!
+
+### Proposals in review
+
+[SE-0329](https://github.com/apple/swift-evolution/blob/main/proposals/0329-clock-instant-date-duration.md): *Clock, Instant, Date, and Duration* is [under review](https://forums.swift.org/t/se-0329-clock-instant-date-and-duration/53309).
+
+> The concepts of time can be broken down into three distinct parts:
+>
+> 1. An item to provide a concept of now plus a way to wake up after a given point in time
+> 2. A concept of a point in time
+> 3. A concept of a measurement in time
+>
+> These three items are respectively a **clock**, an **instant** and a **duration**. The measurement of time can be used for many types of APIs, all the way from the high levels of a concept of a timeout on a network connection, to the amount of time to sleep a task. Currently, the APIs that take measurement of time types take `NSTimeInterval` (aka `TimeInterval`), `DispatchTimeInterval`, and even types like `timespec`.
+
+### Swift Forums
+
+[Ilias Karim](https://forums.swift.org/u/ilias_karim) started [a discussion](https://forums.swift.org/t/pitch-not-contains/53305) about adding `notContains` to the standard library.
+
+> Filter using keypath notation makes functional programming much more succinct and readable in Swift.
+>
+> However, there is not an intuitive standard library way to filter by the opposite of the boolean. I previously proposed [`.toggled` or `.isFalse`](https://forums.swift.org/t/toggled-or-isfalse-property-method-on-bool-for-use-with-keypath-apis/51464) and was met with reasonable push back.
+
+Karl [proposed](https://forums.swift.org/t/filling-buffers-using-randomnumbergenerator/53324) two minor additions to `RandomNumberGenerator`.
+
+> 1. Filling buffers
+> 2. Static member syntax
+
+[Richard Wei](https://twitter.com/rxwei) pitched [an idea](https://forums.swift.org/t/pitch-strongly-typed-regex-captures/53391) about strongly typed regex captures.
+
+> Capturing groups are a commonly used component of regular expressions as they allow the programmer to extract information from matched input. A capturing group collects multiple characters together as a single unit that can be [backreferenced](https://www.regular-expressions.info/backref.html) within the regular expression and accessed in the result of a successful match.
+
+[Joseph Heck](http://twitter.com/heckj/) started a discussion about the terminology questions - behaviors, shells, and possible reductions.
+
+> I'll caveat this with "Yep, these could be all implementation details". In starting to dig through the source for swift-distributed-actors, there are some things I knew the concepts for (basic actor concept, mailboxes, and messages). The distributed actors code steps it up a bit, and uses some terms and phrasing that I wasn't very familiar with. I could guess and infer quite a bit, but I thought it might be best to ask about the specific terms and how they're inter-related.
+
+[Ethan Kusters](https://forums.swift.org/u/ethankusters) addressed improvements for the presentation of non-framework documentation.
+
+> Not all documentation built by Swift-DocC is for frameworks. Today, Swift-DocC will build documentation for any symbol graph input it is provided, which is what allows for custom workflows like [Swift-DocC’s user documentation](https://github.com/apple/swift-docc/blob/main/Sources/DocCDocumentation/DocCDocumentation.docc/DocC.symbols.json) on [Swift.org](https://swift.org/documentation/docc). However, Swift-DocC always describes this documentation as a “Framework” on the top-level page, regardless of the contents of that symbol graph.
+>
+> For example, Swift-DocC’s user documentation on [Swift.org](http://swift.org/) is currently described as a “Framework” on the top-level page when the documentation on that page is about using DocC as a “Tool”, not as a “Framework”.
+
+[Tom Doron](https://twitter.com/TomerDoron) [pitched a](https://forums.swift.org/t/pre-pitch-swiftpm-manifest-based-on-result-builders/53457) SwiftPM manifest based on result builders.
+
+> Swift Package Manager (here after SwiftPM) was released when Swift was made open source in 2016. SwiftPM uses a file named `Package.swift` with which users describe the package's source structure, the build artifacts such as any executables or libraries the build produces, and any dependencies on other packages.
+>
+> SwiftPM’s manifest is a Swift program (a script of sorts) which SwiftPM builds and executes as a separate process in a security sandbox to generate a static data model representing the desired package configuration. Currently, the static representation is based on JSON and the exact format of that JSON is an internal implementation detail. The JSON model is later deserialized and loaded into the parent process memory space, driving SwiftPM’s workflows such as the dependency resolution, build, test , etc.
+
+[Konrad `ktoso` Malawski](https://forums.swift.org/u/ktoso) shared [a proposal](https://forums.swift.org/t/proposal-distributed-actor-isolation/53460) to implement distributed actor isolation.
+
+> This proposal is focusing only on the isolation rules necessary to support distributed actors, and is split out from the large overall Distributed Actors [pitch 8](https://forums.swift.org/t/pitch-distributed-actors/51669/133). Our intent is to propose the various pieces of that very large pitch, as individual yet interconnected proposals, similar to how Swift Concurrency was introduced last year. This way we hope to keep the amount of content reviewable, and also discussions focused on the specific topics at hand.
+
+[Holly Borla](https://twitter.com/hollyborla) pitched [a proposal](https://forums.swift.org/t/pitch-introduce-existential-any/53520) introducing existential `any`.
+
+> Existential types in Swift have an extremely lightweight spelling: a plain protocol name in type context means an existential type. Over the years, this has risen to the level of **active harm** by causing confusion, leading programmers down the wrong path that often requires them to re-write code once they hit a fundamental [limitation of value-level abstraction](https://forums.swift.org/t/improving-the-ui-of-generics/22814#heading--limits-of-existentials). This proposal makes the impact of existential types explicit in the language by annotating such types with `any`.
+
+### Finally
+
+[What's a good way to model a numeric value that *must* be within a certain range?](https://twitter.com/jesse_squires/status/1457792858715418629).
+
+[Sprite Commercial in the Style of a 1993 MacIntosh computer](https://www.youtube.com/watch?app=desktop&v=zQDqYKG4dME).
diff --git a/_posts/2021-12-02-issue-199.md b/_posts/2021-12-02-issue-199.md
new file mode 100644
index 00000000..8be9f6d5
--- /dev/null
+++ b/_posts/2021-12-02-issue-199.md
@@ -0,0 +1,96 @@
+---
+layout: post
+title: ! 'Issue #199'
+author: fassko
+sponsor:
+ link: https://iosacademy.essentialdeveloper.com/p/ios-testing-crash-course-swba028/
+ heading: The Senior iOS Developer Testing Crash Course
+ body: Learn the most up-to-date techniques and strategies for testing new and legacy Swift code in this free practical course for iOS devs who want to become complete Senior iOS Developers.
+ displaylink: iosacademy.essentialdeveloper.com
+---
+
+Hello all! I truly hope you enjoyed Thanksgiving and were able to spend the holiday with your loved ones. Maybe some of you even played Chandler’s invented game of naming all [50 states in 6 minutes](https://www.youtube.com/watch?v=0YKyFV3551w).
+
+The period after Thanksgiving was very productive for the Swift team, and there's a lot of activity to discuss today. But before we jump into it, I'd like to use this opportunity to say that the next issue will be the last issue for me and maybe for this project. Please let me know if anyone is interested in taking over my duties. I would love to see this project stay alive and thrive after I leave.
+
+
+
+{% include sponsor.html %}
+
+### News and community
+
+[Keith Smiley](https://twitter.com/SmileyKeith) [shared](https://forums.swift.org/t/5-5-cherry-pick-triage-process/53574) updates about Swift 5.5 and it's cherry-picking triage process.
+
+[John Sundell](https://twitter.com/johnsundell) wrote [an article](https://www.swiftbysundell.com/articles/count-vs-isEmpty/) exploring how to use `count` vs. `isEmpty` to check whether a collection contains any elements.
+
+[Will Lisac](https://twitter.com/wlisac) [tweeted](https://twitter.com/wlisac/status/1460499369052884992) that [Swift 5.5 Docker images](https://github.com/wlisac/swift-on-balena) for Raspberry Pi are now available.
+
+A great [illustration](https://fbernutz.github.io/images/summaries-ios-interview-topics/swift-evolution.jpg) by [Feli](https://twitter.com/felibe444). Worth to check out her [sketches](https://fbernutz.github.io/sketchnotes/) from various conferences.
+
+[Max Desiatov](https://twitter.com/MaxDesiatov) [announced](https://forums.swift.org/t/swiftwasm-5-5-0-is-now-available/53760) that the [SwiftWasm 5.5.0](https://blog.swiftwasm.org/posts/5-5-released/) is now available.
+
+### Accepted proposals
+
+[SE-0328](https://github.com/apple/swift-evolution/blob/main/proposals/0328-structural-opaque-result-types.md) *Structural opaque result type* was [accepted with modifications](https://forums.swift.org/t/accepted-with-modifications-se-0328-structural-opaque-result-type/53789).
+
+> During the review, there were two main areas of discussion:
+>
+> * The spelling of optional types. The proposal leaves this as `(some P)?` even though `some P?` is more succinct and could potentially be allowed as sugar. The core team agrees with this more conservative approach, which could be revisited later after more experience with the feature.
+> * The use of `some` in "consuming" rather than "producing" position when returning function types i.e. `f() -> (some P) -> Void`. Discussion of other uses of the `some` keyword is ongoing, and there was concern about potential conflict with those future uses. Since the use of opaque result types in consuming position is not especially useful (such functions are uncallable in all but a few circumstances) the core team has decided to subset out this use, requiring opaque result types only in the return value of returned function types for now.
+
+### Proposals in review
+
+[SE-0332](https://github.com/apple/swift-evolution/blob/main/proposals/0332-swiftpm-command-plugins.md): *Package Manager Command Plugins* is [under review](https://forums.swift.org/t/se-0332-package-manager-command-plugins/53769).
+
+> SE-0303 introduced the ability to define _build tool plugins_ in SwiftPM, allowing custom tools to be automatically invoked during a build. This proposal extends that plugin support to allow the definition of custom _command plugins_ — plugins that users can invoke directly from the SwiftPM CLI, or from an IDE that supports Swift Packages, in order to perform custom actions on their packages.
+
+[SE-0331](https://github.com/apple/swift-evolution/blob/main/proposals/0331-remove-sendable-from-unsafepointer.md): *Remove Sendable conformance from unsafe pointer types* is [under review](https://forums.swift.org/t/se-0331-remove-sendable-conformance-from-unsafe-pointer-types/53768).
+
+> [SE-0302](https://github.com/apple/swift-evolution/blob/main/proposals/0302-concurrent-value-and-concurrent-closures.md) introduced the `Sendable` protocol, including `Sendable` requirements for various language constructs, conformances of various standard library types to `Sendable`, and inference rules for non-public types to implicitly conform to `Sendable`.
+>
+> Experience with `Sendable` shows that this formulation is unnecessarily dangerous and has unexpected negative consequences for implicit conformance.
+
+[SE-0333](https://github.com/apple/swift-evolution/blob/main/proposals/0333-with-memory-rebound.md): *Expand usability of withMemoryRebound* is [under review](https://forums.swift.org/t/se-0333-expand-usability-of-withmemoryrebound/53799).
+
+> The function `withMemoryRebound(to:capacity:_ body:)`
+executes a closure while temporarily binding a range of memory to a different type than the callee is bound to.
+We propose to lift some notable limitations of `withMemoryRebound` and enable rebinding to a larger set of types,
+as well as rebinding from raw memory pointers and buffers.
+>
+> Note this proposal is running concurrently with [SE-0334](https://forums.swift.org/t/se-0334-pointer-usability-improvements/) which also relates to unsafe pointer usability.
+
+[SE-0334](https://github.com/apple/swift-evolution/blob/main/proposals/0334-pointer-usability-improvements.md): *Pointer Usability Improvements* is [under review](https://forums.swift.org/t/se-0334-pointer-usability-improvements/53800).
+
+> This proposal introduces some quality-of-life improvements for `UnsafePointer` and its `Mutable` and `Raw` variants.
+>
+> 1. Add an API to obtain an `UnsafeRawPointer` instance that is advanced to a given alignment from its starting point.
+> 2. Add an API to obtain a pointer to a stored property of an aggregate `T`, given an `UnsafePointer`.
+> 3. Add the ability to compare pointers of any two types.
+>
+> Note this proposal is running concurrently with [SE-0333](https://forums.swift.org/t/se-0333-expand-usability-of-withmemoryrebound/) which also relates to unsafe pointer usability.
+
+### Swift Forums
+
+[Ethan Kusters](https://forums.swift.org/u/ethankusters) started [a discussion](https://forums.swift.org/t/support-hosting-docc-archives-in-static-hosting-environments/53572) about support hosting DocC archives in static hosting environments.
+
+> This post discusses an enhancement to Swift-DocC and Swift-DocC-Render that will allow developers to build DocC archives that can be hosted without custom routing. This is specifically designed to enable DocC to be used in additional static hosting environments, most notably GitHub Pages.
+>
+> This change is meant as a quick solution to address a pressing need, and provides general goodness. But please know that we’ve heard the community’s feedback that they would love for Swift-DocC to directly emit static HTML, and this feature is high on the priority list.
+
+[Sam Deane](https://twitter.com/samdeane) pitched [an idea](https://forums.swift.org/t/default-initable-protocol/53723) to implement a default initable protocol.
+
+> I've come across factory-type situations where I've ended up making a protocol to represent that "this type can be constructed with a default init that takes no arguments".
+>
+> I've found myself wondering (a) whether this protocol already exists somewhere in the standard library, and (b) whether Swift could auto-conform any type to it if an init() exists for it.
+
+[A good reminder](https://forums.swift.org/t/a-built-in-angle-type/53726) that a library [Swift Numerics](https://github.com/apple/swift-numerics) does exist.
+
+Guillaume Lessard pitched [a proposal](https://forums.swift.org/t/pitch-buffer-partial-initialization-better-buffer-slices/53795) to make slices of buffers more useful, especially with respect to partial initialization of buffers.
+
+> Sub-sequences of the `UnsafeBufferPointer` family have all the `[Mutable]Collection` API of `UnsafeBufferPointer`, but have none of their buffer-specific API. This makes partial initialization of a buffer difficult, among other tasks.
+
+### Finally
+
+[iPhone Development Tutorial - 1 - Installing Xcode and the iPhone SDK.](https://www.youtube.com/watch?v=abcMmyhKCno).
+
+[The History of the Web](https://thehistoryoftheweb.com/timeline/).
diff --git a/_posts/2021-12-16-issue-200.md b/_posts/2021-12-16-issue-200.md
new file mode 100644
index 00000000..e78e2eb1
--- /dev/null
+++ b/_posts/2021-12-16-issue-200.md
@@ -0,0 +1,111 @@
+---
+layout: post
+title: ! 'Issue #200'
+author: fassko
+sponsor:
+ link: https://getstream.io/chat/sdk/ios/
+ heading: Build real-time chat messaging in less time with Stream
+ body: Rapidly ship in-app messaging with Stream’s highly reliable chat infrastructure and feature-rich SDKs. Drive in-app conversion, engagement, and retention.
+ displaylink: getstream.io/chat/sdk/ios/
+---
+
+> In every end, there is also a beginning.
+
+This issue #200 is my last as the main contributor to this project. I want to thank [Jesse Squires](https://twitter.com/jesse_squires), who started this project, and [Bas Broek](https://twitter.com/BasThomas), who continued later on and trusted me to run it. I also want to thank all the contributors who have helped with writing, reviewing, or providing the content. It is indeed a community-run project. Thank you!
+
+Now let's get to the news.
+
+
+
+{% include sponsor.html %}
+
+### Podcasts
+
+In [episode 110](https://www.swiftbysundell.com/podcast/110/) of the Swift by Sundell podcast, [Tim Condon](https://twitter.com/0xTim), joins [John Sundell](https://twitter.com/johnsundell) to discuss how both client and server-side Swift developers could utilize the new built-in concurrency system, as well as how distributed actors and other upcoming language features might continue to make Swift even more capable on the server.
+
+### News and community
+
+Six years ago, on the 3rd of December 2015, the Swift language was [open-sourced](https://www.swift.org/blog/welcome/).
+
+Xcode 13.2 has been released. The release tumbled a bit, but has some notable [Swift features](https://developer.apple.com/documentation/xcode-release-notes/xcode-13_2-release-notes#Swift).
+
+[Swift Playgrounds 4 is now available.](https://developer.apple.com/news/?id=v868vy6e) Swift Playgrounds is the best and easiest way to learn how to code. And with Swift Playgrounds 4, you have the tools to build iPhone and iPad apps right on iPad and submit them directly to App Store Connect.
+
+Amazon Web Services [announced](https://twitter.com/awsdevelopers/status/1466476358389874704) that [AWS SDK for the Swift programming language](https://t.co/0x27sFTE3p) is now available in developer preview.
+
+[Vincent Pradeilles](https://twitter.com/v_pradeilles) posted [a video](https://www.youtube.com/watch?v=Ii1mDtDr3xo) about Swift's standard library.
+
+### Commits and pull requests
+
+[Alejandro Alonso](https://github.com/Azoy) merged [a pull request](https://github.com/apple/swift/pull/40340) that drops ICU.
+
+### Accepted proposals
+
+[SE-0331](https://github.com/apple/swift-evolution/blob/main/proposals/0331-remove-sendable-from-unsafepointer.md) *Remove Sendable conformance from unsafe pointer types* was [accepted](https://forums.swift.org/t/accepted-se-0331-remove-sendable-conformance-from-unsafe-pointer-types/53979).
+
+[SE-0332](https://github.com/apple/swift-evolution/blob/main/proposals/0332-swiftpm-command-plugins.md) *Package Manager Command Plugins* was [accepted with modifications](https://forums.swift.org/t/accepted-with-modifications-se-0332-package-manager-command-plugins/54074).
+
+### Proposals in review
+
+[SE-0335](https://github.com/apple/swift-evolution/blob/main/proposals/0335-existential-any.md): *Introduce existential `any`* is [under review](https://forums.swift.org/t/se-0335-introduce-existential-any/53934).
+
+> Existential types in Swift have an extremely lightweight spelling: a plain protocol name in type context means an existential type. Over the years, this has risen to the level of **active harm** by causing confusion, leading programmers down the wrong path that often requires them to re-write code once they hit a fundamental [limitation of value-level abstraction](https://forums.swift.org/t/improving-the-ui-of-generics/22814#heading--limits-of-existentials). This proposal makes the impact of existential types explicit in the language by annotating such types with `any`.
+
+[SE-0336](https://github.com/apple/swift-evolution/blob/main/proposals/0336-distributed-actor-isolation.md): *Distributed actor isolation* is [under review](https://forums.swift.org/t/se-0336-distributed-actor-isolation/53939).
+
+> With the recent introduction of [actors](https://github.com/apple/swift-evolution/blob/main/proposals/0306-actors.md) to the language, Swift gained powerful and foundational building blocks for expressing _thread-safe_ concurrent programs. This proposal is the first in a series of proposals aiming to extend Swift's actor runtime with the concept of _distributed actors_, allowing developers leverage the actor model not only in local, but also distributed settings.
+>
+> With distributed actors, we acknowledge that the world we live in is increasingly built around distributed systems, and that we should provide developers with better tools to work within those environments. We aim to simplify and push the state-of-the-art for distributed systems programming in Swift as we did with concurrent programming with local actors and Swift’s structured concurrency approach embedded in the language.
+>
+> This proposal focuses on the extended actor isolation and type-checking aspects of distributed actors.
+
+[SSWG-0018](https://github.com/swift-server/sswg/blob/main/proposals/0018-mqtt-nio.md): *MQTTNIO Proposal* is [under review](https://forums.swift.org/t/sswg-0018-mqttnio-proposal/54004).
+
+> There are a number of Swift MQTT libraries out there but many are not built on top of SwiftNIO. And many only support one version of the protocol or don’t provide WebSocket or TLS connections. MQTTNIO provides all of these. The library has also recently gained new Swift concurrency APIs.
+
+[SE-0327](https://github.com/apple/swift-evolution/blob/main/proposals/0327-actor-initializers.md): *On Actors and Initialization* is [under a second review](https://forums.swift.org/t/se-0327-second-review-on-actors-and-initialization/54093).
+
+> This proposal has undergone a number of revisions in response to feedback from the [first review 1](https://forums.swift.org/t/se-0327-on-actors-and-initialization/53053), which the author has summarized as:
+>
+> 1. Actor initializers that are not isolated to the actor will now allow you to do anything you normally can from a `nonisolated` method. In exchange, Swift will automatically reject accesses to stored properties that might be unsafe. Here is the [problem description](https://github.com/apple/swift-evolution/blob/main/proposals/0327-actor-initializers.md#overly-restrictive-non-async-initializers) and [proposed solution 3](https://github.com/apple/swift-evolution/blob/main/proposals/0327-actor-initializers.md#initializers-with-nonisolated-self).
+> 2. Deinitializers of an actor can no longer access non-sendable stored properties of the instance. Here is the [problem description](https://github.com/apple/swift-evolution/blob/main/proposals/0327-actor-initializers.md#data-races-in-deinitializers) and [proposed solution 1](https://github.com/apple/swift-evolution/blob/main/proposals/0327-actor-initializers.md#deinitializers)
+> 3. The default value of a type's stored property is evaluated in a non-isolated context. Here is the [problem description](https://github.com/apple/swift-evolution/blob/main/proposals/0327-actor-initializers.md#stored-property-isolation) and [proposed solution](https://github.com/apple/swift-evolution/blob/main/proposals/0327-actor-initializers.md#global-actor-isolation-and-instance-members)
+> 4. The `convenience` keyword is no longer required to define a delegating initializer of an actor. Here is the [problem description ](https://github.com/apple/swift-evolution/blob/main/proposals/0327-actor-initializers.md#initializer-delegation) and [proposed rules](https://github.com/apple/swift-evolution/blob/main/proposals/0327-actor-initializers.md#delegating-initializers) for their delegating initializers, which is continued in the Sendability section.
+
+### Swift Forums
+
+[Evan Wilde](https://forums.swift.org/u/etcwilde) pitched [a proposal](https://forums.swift.org/t/pitch-unavailability-from-asynchronous-contexts/53877) the `@unavailableFromAsync` attribute.
+
+> The Swift concurrency model allows tasks to suspend and resume on different threads. While this behaviour allows higher utility of computational resources, there are some nasty pitfalls that can spring on an unsuspecting programmer. One such pitfall is the undefined behaviour from unlocking a `pthread_mutex_t` from a different thread than the thread that holds the lock. Reading from and writing to thread-local storage across suspension points can also result in unintended behavior, since the operation may be resuming on a different thread.
+
+[Tom Doron](https://twitter.com/tomerdoron) pitched [an idea](https://forums.swift.org/t/pitch-package-manager-statically-link-swift-runtime-libraries-by-default-on-supported-platforms/53900) to statically link Swift runtime libraries by default on supported platforms.
+
+> Swift 5.3.1 introduced [statically linking the Swift runtime libraries on Linux](https://forums.swift.org/t/static-linking-on-linux-in-swift-5-3-1/). With this feature, users can set the `--static-swift-stdlib` flag when invoking SwiftPM commands (or the long form `-Xswiftc -static-stdlib`) in order to statically link the Swift runtime libraries into the program.
+>
+> On some platforms, such as Linux, this is often the preferred way to link programs, since the program is easier to deploy to the target server or otherwise share.
+>
+> This proposal explores making it SwiftPM's default behavior when building executable programs on such platforms.
+
+[Frederick Kellison-Linn](https://forums.swift.org/u/jumhyn) pitched [a proposal](https://forums.swift.org/t/swift-6-reconsider-escaping-for-optional-function-type-parameters/53932) to reconsider `@escaping` for optional function-type parameters.
+
+[Kavon Farvardin]() updated [the proposal](https://forums.swift.org/t/pitch-2-on-actors-and-initialization/53972) on Actors and Initialization.
+
+> Since the proposal differs significantly from the first review, this is a pitch. Here's a very informal and incomplete summary of the major functionality proposed, along with some links into the document itself for more details:
+
+> 1. Actor initializers that are not isolated to the actor will now allow you to do anything you normally can from a `nonisolated` method. In exchange, Swift will automatically reject accesses to stored properties that might be unsafe. Here is the [problem description 2](https://github.com/kavon/swift-evolution/blob/actor-initializers-review2/proposals/0327-actor-initializers.md#overly-restrictive-non-async-initializers) and [proposed solution 1](https://github.com/kavon/swift-evolution/blob/actor-initializers-review2/proposals/0327-actor-initializers.md#initializers-with-nonisolated-self).
+> 2. Deinitializers of an actor can no longer access non-sendable stored properties of the instance. Here is the [problem description 1](https://github.com/kavon/swift-evolution/blob/actor-initializers-review2/proposals/0327-actor-initializers.md#data-races-in-deinitializers) and [proposed solution](https://github.com/kavon/swift-evolution/blob/actor-initializers-review2/proposals/0327-actor-initializers.md#deinitializers)
+> 3. A type's stored property cannot have a default value if its isolation is not compatible with its initializers. Here is the [problem description](https://github.com/kavon/swift-evolution/blob/actor-initializers-review2/proposals/0327-actor-initializers.md#stored-property-isolation) and [proposed solution](https://github.com/kavon/swift-evolution/blob/actor-initializers-review2/proposals/0327-actor-initializers.md#global-actor-isolation-and-instance-members)
+> 4. The `convenience` keyword is no longer required to define a delegating initializer of an actor. Here is the [problem description 3](https://github.com/kavon/swift-evolution/blob/actor-initializers-review2/proposals/0327-actor-initializers.md#initializer-delegation) and [proposed rules 2](https://github.com/kavon/swift-evolution/blob/actor-initializers-review2/proposals/0327-actor-initializers.md#delegating-initializers) for their delegating initializers, which is continued in the Sendability section.
+
+Updates from Swift on the Server Workgroup:
+
+* [1st Sep 2021](https://forums.swift.org/t/1st-sep-2021/53982)
+* [15th September 2021](https://forums.swift.org/t/15th-september-2021/54002)
+* [September 29, 2021](https://forums.swift.org/t/september-29-2021/53926)
+* [October 13th, 2021](https://forums.swift.org/t/october-13th-2021/53990)
+* [October 27th, 2021](https://forums.swift.org/t/october-27th-2021/53984)
+* [November 10, 2021](https://forums.swift.org/t/november-10-2021/54031)
+
+### Finally
+
+This time I will leave [my website](https://kristaps.me/) in the final section.
diff --git a/_posts/2022-06-22-issue-201.md b/_posts/2022-06-22-issue-201.md
new file mode 100644
index 00000000..c3150572
--- /dev/null
+++ b/_posts/2022-06-22-issue-201.md
@@ -0,0 +1,18 @@
+---
+layout: post
+title: ! 'Issue #201'
+author: appforce1
+---
+
+This is it. The final goodbye of Swift Weekly Brief.
+
+We are now dormant for almost half a year and after a quick discussion Kristaps and I feel it is time to make good on our promise to delete the entire list's data.
+
+We loved having you as readers, but we love respecting your data even more.
+
+We do want to suggest another list to look at:
+
+- Recently Cihat has been killing it on his new list with a very similar purpose to ours. If you liked Swift Weekly Brief, you will love his newsletter. So [sign up on his Twitter profile](https://twitter.com/Jeehut), give him a follow too. If you are not into Twitter or would like to use a dedicated email address: [This is the same newsletter but on Revue](https://se-monthly.flinedev.com/)
+
+Thank you for you time and attention,
+[Kristaps](https://kristaps.me/) and [Jeroen](https://appforce1.net)
diff --git a/authors.html b/authors.html
index 9e8d2aff..a514d1fa 100644
--- a/authors.html
+++ b/authors.html
@@ -16,16 +16,16 @@ {{ page.title }}
{% assign author_posts = each_item.items %}