Issue 183

Gemfile.lock

@@ -237,7 +237,6 @@ GEM
       rb-fsevent (~> 0.10, >= 0.10.3)
       rb-inotify (~> 0.9, >= 0.9.10)
     mercenary (0.3.6)
-    mini_portile2 (2.5.0)
     minima (2.5.1)
       jekyll (>= 3.5, < 5.0)
       jekyll-feed (~> 0.9)
@@ -246,9 +245,6 @@ GEM
     multipart-post (2.1.1)
     nap (1.1.0)
     no_proxy_fix (0.1.2)
-    nokogiri (1.11.3)
-      mini_portile2 (~> 2.5.0)
-      racc (~> 1.4)
     nokogiri (1.11.3-x86_64-darwin)
       racc (~> 1.4)
     octokit (4.20.0)

_drafts/2021-04-22-issue-183.md

@@ -0,0 +1,120 @@
+---
+layout: post
+title: ! 'Issue #183'
+author: fassko
+sponsor:
+	link: https://www.git-tower.com
+	heading: A Better Way to Work With Git
+	body: |
+	    Imagine you could undo mistakes in Git with a simple keyboard shortcut, use Interactive Rebase via drag and drop or clone a repository from GitHub with a single click.
+
+	    Tower lets you do exactly that and so much more. Finally take advantage of Git’s powerful feature set - in a beautiful GUI that will make you more productive every single day. Try it free for 30 days.
+	displaylink: www.git-tower.com
+	custom-utm: ""
+---
+
+I want to thank [Jeroen](https://twitter.com/AppForce1) for helping out with last week's issue. He did a great job spicing up the usual flow. How did you like it? [Let us know](https://twitter.com/swiftlybrief).
+
+We finally have the [Xcode 12.5 RC](https://developer.apple.com/documentation/xcode-release-notes/xcode-12_5-release-notes#Swift), and it has some notable Swift language fixes and improvements.
+
+In the last two weeks it seems like the Swift core team have woken up after a winter slumber. Dozens of proposals are now in review and many have been returned.
+
+Now let's go to the news!
+
+<!--excerpt-->
+
+{% include sponsor.html %}
+
+### News and community
+
+[Xcode 12.5 RC](https://developer.apple.com/documentation/xcode-release-notes/xcode-12_5-release-notes#Swift) is out and has a lot of new Swift features, improvements, and fixes.
+
+[Vincent Pradeilles](https://twitter.com/v_pradeilles) created [a video](https://www.youtube.com/watch?v=pSTU6UlA4uw) explaining why we should read Swift Evolution Proposals.
+
+[Leonardo Maia Pugliese](https://twitter.com/Leo_Pugliese) wrote [an article](https://holyswift.app/single-forward-pipe-operator-in-swift) exploring the single forward pipe operator in Swift.
+
+[Mishal Shah](https://twitter.com/mishaldshah) informed us that Swift 5.5 nightly development [snapshots](https://swift.org/download/#snapshots) are now available.
+
+### Commits and pull requests
+
+[David Goldman](https://github.com/DavidGoldman) created [a pull request](https://github.com/apple/sourcekit-lsp/pull/388) that adds support for `clangd`'s semantic highlighting.
+
+[Slava Pestov](https://twitter.com/slava_pestov) merged [a pull request](https://github.com/apple/swift/pull/36940) that fixes the issue where `SIL` type lowering did not commute with `subst()`.
+
+[Joakim Hassila](https://github.com/hassila) created [a pull request](https://github.com/apple/swift-nio/pull/1804) that adds support for `io_uring` for the SwiftNIO project.
+
+[Cory Benfield](https://github.com/Lukasa) merged [a pull request](https://github.com/apple/swift-nio/pull/1701) that adds `async`/`await` support to the SwiftNIO.
+
+[Saleem Abdulrasool](https://twitter.com/compnerd) created [a pull request](https://github.com/swift-server/swift-backtrace/pull/42) that adds backtrace support for Windows.
+
+### Returned proposals
+
+[SE-0305](https://forums.swift.org/t/se-0305-package-manager-binary-target-improvements/45589) has been [returned for revision](https://forums.swift.org/t/returned-for-revision-se-0305-package-manager-binary-target-improvements/47441).
+
+> The feedback to the idea of extending SwiftPM to support new kind of binary targets, in conjunction with the plugin system proposed in [SE-0303](https://github.com/apple/swift-evolution/blob/main/proposals/0303-swiftpm-extensible-build-tools.md) was positive. However, given [SE-0303](https://github.com/apple/swift-evolution/blob/main/proposals/0303-swiftpm-extensible-build-tools.md) was returned to review, as well as feedback from reviewers requesting additional details on the structure suggested on [SE-0305](https://github.com/apple/swift-evolution/blob/main/proposals/0305-swiftpm-binary-target-improvements.md), the core team decided to ask that [SE-0305](https://github.com/apple/swift-evolution/blob/main/proposals/0305-swiftpm-binary-target-improvements.md) is refined alongside [SE-0303](https://github.com/apple/swift-evolution/blob/main/proposals/0303-swiftpm-extensible-build-tools.md).
+
+### Proposals in review
+
+[SE-0306](https://github.com/apple/swift-evolution/blob/main/proposals/0306-actors.md): *Actors* is [under a second review](https://forums.swift.org/t/se-0306-second-review-actors/47291).
+
+> The core team sees two competing draws for consistency here—first, as Chris notes, in other places where Swift models API design, `let` is externally treated equivalently with a get-only `var`, and by that principle, actors should follow suit and not expose `let`s as implicitly `nonisolated` outside of the actor even if they are immutable. That would reserve for the actor the ability to evolve the interface into an internally-mutable variable, or get-only computed property, without breaking API or ABI. It would also result in a consistent rule for how `isolated` and `nonisolated` apply to actor members; instead of `let`s being a special case, _any_ actor declaration would require `nonisolated` to be explicitly annotated to declare it as safe to access from outside the actor without isolation.
+> 
+> On the other hand, "`let`s are immutable and safe to share across threads" has also been a common message through Swift's history, and it could seem boilerplatey to require an explicit annotation on top of `let` to say that, yes, this immutable value is actually immutable. If actors in practice end up carrying a lot of immutable state, the annotation burden could be onerous. The core team would like to hear from the community, particularly adopters who have experimented with actors, to get more signal about how much burden treating the isolation `let`s equivalently with other declarations will be in practice.
+
+[SE-0310](https://github.com/apple/swift-evolution/blob/main/proposals/0310-effectful-readonly-properties.md): *Effectful Read-only Properties* is [under a review](https://forums.swift.org/t/se-0310-effectful-read-only-properties/47401).
+
+> Nominal types such as classes, structs, and enums in Swift support [computed properties](https://docs.swift.org/swift-book/LanguageGuide/Properties.html) and [subscripts](https://docs.swift.org/swift-book/LanguageGuide/Subscripts.html), which are members of the type that invoke programmer-specified computations when getting or setting them.  The recently accepted proposal [SE-0296](https://github.com/apple/swift-evolution/blob/main/proposals/0296-async-await.md) introduced asynchronous functions via `async`, in conjunction with `await`, but did not specify that computed properties or subscripts can support effects like asynchrony.  Furthermore, to take full advantage of `async` properties, the ability to specify that a property `throws` is also important.
+
+[SE-0305](https://github.com/apple/swift-evolution/blob/main/proposals/0305-swiftpm-binary-target-improvements.md): *Package Manager Binary Target Improvements* is [under a second review](https://forums.swift.org/t/se-0305-2nd-review-package-manager-binary-target-improvements/47439).
+
+> The Swift Package Manager’s binaryTarget type lets packages vend libraries that either cannot be built in Swift Package Manager for technical reasons, or for which the source code cannot be published for legal or other reasons.
+> 
+> In the current version of SwiftPM, binary targets only support libraries in an Xcode-oriented format called XCFramework, and only for Apple platforms.
+
+[SE-0303](https://github.com/apple/swift-evolution/blob/main/proposals/0303-swiftpm-extensible-build-tools.md): *Package Manager Extensible Build Tools* is [under a second review](https://forums.swift.org/t/se-0303-2nd-review-package-manager-extensible-build-tools/47438).
+
+> This is a proposal for extensible build tools support in Swift Package Manager. The initial set of functionality is intentionally basic, and focuses on a general way of allowing build tool plugins to add commands to the build graph. The approach is to:
+> 
+> * provide a scalable way for packages to define plugins that can provide build-related capabilities
+> * support a narrowly scoped initial set of possible capabilities that plugins can provide
+> 
+> The set of possible capabilities can then be extended in future SwiftPM versions. The goal is to provide short-term support for common tasks such as source code generation, with a design that can scale to more complex tasks in the future.
+> 
+> This proposal depends on improvements to the existing Binary Target type in SwiftPM — those details are the subject of the separate proposal [SE-0305](https://github.com/apple/swift-evolution/blob/main/proposals/0305-swiftpm-binary-target-improvements.md).
+
+[SE-0311](https://github.com/apple/swift-evolution/blob/main/proposals/0311-task-locals.md): *Task-local values* is [under a review](https://forums.swift.org/t/se-0311-task-local-values/47478).
+
+> This proposal is part of the larger [concurrency feature](https://forums.swift.org/t/swift-concurrency-roadmap/41611).  There have been quite a lot of these reviews, and there are a quite a few more coming, I'm afraid; still, we seem to have got through most of the more difficult ones.  Thank you for your patience with all this.
+
+[SE-0309](https://github.com/apple/swift-evolution/blob/main/proposals/0309-unlock-existential-types-for-all-protocols.md): *Unlock existential types for all protocols* is [under a review](https://forums.swift.org/t/se-0309-unlock-existential-types-for-all-protocols/47515).
+
+> Swift allows one to use a protocol as a type when its _requirements_ meet a rather unintuitive list of criteria, among which is the absence of associated type requirements, and emits the following error otherwise: `Protocol can only be used as a generic constraint because it has 'Self' or associated type requirements`. Our objective is to _alleviate_ this limitation to impact only the ability to access certain members (instead of preemptively sealing off the entire protocol interface), and adjust the specified criteria to further reduce the scope of the restriction.
+> 
+> This proposal is a preamble to a series of changes aimed at generalizing value-level abstraction (existentials) and improving its interaction with type-level abstraction (generics). For an in-depth exploration of the relationships among different built-in abstractions models, we recommend reading the [design document for improving the UI of the generics model](https://forums.swift.org/t/improving-the-ui-of-generics/22814).
+> 
+> Swift-Evolution Pitch Threads: [Thread #1](https://forums.swift.org/t/lifting-the-self-or-associated-type-constraint-on-existentials/18025), [Thread #2](https://forums.swift.org/t/unlock-existential-types-for-all-protocols/40665)
+
+### Swift Forums
+
+[Tim Vermeulen](https://forums.swift.org/u/timv) pitched a proposal to add `indexed()` and `Collection` conformances for `enumerated()` and `zip(_:_:)`.
+
+> This proposal aims to fix the lack of `Collection` conformance of the sequences returned by `zip(_:_:)` and `enumerated()`, preventing them from being used in a context that requires a `Collection`. Also included is the addition of the `indexed()` method on `Collection` as a more ergonomic, efficient, and correct alternative to `c.enumerated()` and `zip(c.indices, c)`.
+
+[Jonathan G.](https://forums.swift.org/u/1oo7) started an interesting discussion about making the "Undocumented/Private API" signifier `_` official.
+
+> There is an undocumented convention in Swift, of appending an underscore "_" to a public symbol or attribute to communicate some special meaning.
+> 
+> However, you will not find any mention of this practice within Swift's own documentation on [swift.org](http://swift.org/), nor any explanation of the often subtle differences in meaning of "_". (Please correct me if I'm wrong. I did several searches and came up with nothing, and several read-throughs.)
+
+[Kelvin Ma](https://github.com/kelvin13) started [a discussion](https://forums.swift.org/t/why-is-dictionary-position-not-settable/47435) about why  `Dictionary[position:]` is not settable?
+
+> The `Dictionary` type exposes a non-nil subscript [`[position:]`](https://developer.apple.com/documentation/swift/dictionary/2831255-subscript) which takes a `Dictionary.Index`. I always wondered why this subscript is `get`-only, since I often find myself wanting to check if a key-value pair is present in the dictionary, and then mutate the value only if it exists.
+
+Swift on the Server Workgroup meeting notes:
+
+* [March 17th, 2021](https://forums.swift.org/t/march-17th-2021/47427)
+* [March 31st, 2021](https://forums.swift.org/t/march-31st-2021/47404)
+
+### Finally
+
+[When you forget to get rid of your debugging statements](https://twitter.com/towernter/status/1383815365520629760)