Document the upcoming feature flags implemented in Swift 5.8 (#1964)

Author: DougGregor

proposals/0274-magic-file.md

@@ -3,8 +3,8 @@
 * Proposal: [SE-0274](0274-magic-file.md)
 * Authors: [Becca Royal-Gordon](https://github.com/beccadax), [Dave DeLong](https://github.com/davedelong)
 * Review Manager: [Ben Cohen](https://github.com/airspeedswift/)
-* Status: **Accepted (2020-02-26)**
-* Implementation: Prototype in master behind `-Xfrontend -enable-experimental-concise-pound-file`; revisions in [apple/swift#29412](https://github.com/apple/swift/pull/29412)
+* Status: **Implemented (Swift 5.8)**
+* Upcoming feature flag: `ConciseMagicFile`
 * Decision Notes: [Review #1](https://forums.swift.org/t/se-0274-concise-magic-file-names/32373/50), [Review #2](https://forums.swift.org/t/re-review-se-0274-concise-magic-file-names/33171/11), [Additional Commentary](https://forums.swift.org/t/revisiting-the-source-compatibility-impact-of-se-0274-concise-magic-file-names/37720)
 * Next Proposal: [SE-0285](0285-ease-pound-file-transition.md)
 
@@ -154,6 +154,8 @@ These are implemented in the unmerged [apple/swift#29412](https://github.com/app
 
 All existing source code will continue to compile with this change, and `#file`'s documentation never specified precisely what its contents were; in one of the pitch threads, [Ben Cohen](https://forums.swift.org/t/concise-magic-file-names/31297/19) said that this is sufficient to satisfy Swift's source compatibility requirements. However, the proposal *will* cause behavior to change in existing code, and in some cases it will change in ways that cause existing code to behave incorrectly when run. Code that is adversely affected by this change can access the previous behavior by using `#filePath` instead of `#file`.
 
+The change to the behavior of `#file` was deferred to the next major language version (Swift 6). However, it can be enabled with the [upcoming feature flag](0362-piecemeal-future-features.md) `ConciseMagicFile`.
+
 ## Effect on ABI stability
 
 None. `#file` is a compile-time feature; existing binaries will continue to work as they did before.

proposals/0286-forward-scan-trailing-closures.md

@@ -4,6 +4,7 @@
 * Author: [Doug Gregor](https://github.com/DougGregor)
 * Review Manager: [John McCall](https://github.com/rjmccall)
 * Status: **Implemented (Swift 5.3)**
+* Upcoming feature flag: `ForwardTrailingClosures` (implemented in Swift 5.8)
 * Implementation: [apple/swift#33092](https://github.com/apple/swift/pull/33092)
 * Toolchains: [Linux](https://ci.swift.org/job/swift-PR-toolchain-Linux/404//artifact/branch-master/swift-PR-33092-404-ubuntu16.04.tar.gz), [macOS](https://ci.swift.org/job/swift-PR-toolchain-osx/579//artifact/branch-master/swift-PR-33092-579-osx.tar.gz)
 * Discussion: ([Pitch #1](https://forums.swift.org/t/pitch-1-forward-scan-matching-for-trailing-closures-source-breaking/38162)), ([Pitch #2](https://forums.swift.org/t/pitch-2-forward-scan-matching-for-trailing-closures/38491))
@@ -19,7 +20,7 @@ However, the backward-scan matching rule makes it hard to write good API that us
 ## Motivation
 
 Several folks noted the downsides of the "backward" matching rule. The rule itself is described in the [detailed design](https://github.com/apple/swift-evolution/blob/master/proposals/0279-multiple-trailing-closures.md#detailed-design) section of SE-0279 (search for "backward"). To understand the problem with the backward rule, let's try to declare the UIView [`animate(withDuration:animations:completion:)`](https://developer.apple.com/documentation/uikit/uiview/1622515-animate) method in the obvious way to make use of SE-0279:
- 
+
 ```swift
 class func animate(
     withDuration duration: TimeInterval, 
@@ -301,6 +302,8 @@ trailingClosureBothDirections(g: { $0 * $1 })
 
 This suppresses the warning and eliminates the ambiguity, so the code behaves the same across all overload sets.
 
+The Swift 6 and newer behavior can be enabled in existing language modes with the [upcoming feature flag](0362-piecemeal-future-features.md) `ForwardTrailingClosures`.
+
 ### Workaround via overload sets
 
 APIs like the above that depend on the backward scan can be reworked to provide the same client API. The basic technique involves removing the default arguments, then adding additional overloads to create the same effect. For example, drop the default argument of `finishHandler` so that the heuristic will kick in to fix calls with a single unlabeled trailing closure:

proposals/0335-existential-any.md

@@ -4,6 +4,7 @@
 * Authors: [Holly Borla](https://github.com/hborla)
 * Review Manager: [Doug Gregor](https://github.com/DougGregor)
 * Status: **Implemented (Swift 5.6)**
+* Upcoming feature flag: `ExistentialAny` (implemented in Swift 5.8)
 * Implementation: [apple/swift#40282](https://github.com/apple/swift/pull/40282)
 * Decision Notes: [Acceptance](https://forums.swift.org/t/accepted-with-modifications-se-0335-introduce-existential-any/54504)
 
@@ -95,6 +96,8 @@ let pq1: P & Q = S() // error
 let pq2: any P & Q = S() // okay
 ```
 
+The Swift 6 behavior can be enabled in earlier language modes with the [upcoming feature flag](0362-piecemeal-future-features.md) `ExistentialAny`.
+
 ## Detailed design
 
 ### Grammar of explicit existential types

proposals/0354-regex-literals.md

@@ -4,6 +4,7 @@
 * Authors: [Hamish Knight](https://github.com/hamishknight), [Michael Ilseman](https://github.com/milseman), [David Ewing](https://github.com/DaveEwing)
 * Review Manager: [Ben Cohen](https://github.com/airspeedswift)
 * Status: **Implemented (Swift 5.7)**
+* Upcoming feature flag: `BareSlashRegexLiterals` (implemented in Swift 5.8)
 * Implementation: [apple/swift#42119](https://github.com/apple/swift/pull/42119), [apple/swift#58835](https://github.com/apple/swift/pull/58835)
   * Bare slash syntax `/.../` available with `-enable-bare-slash-regex`
 * Review: ([first pitch](https://forums.swift.org/t/pitch-regular-expression-literals/52820))
@@ -408,7 +409,7 @@ As explored above, the parsing of `/.../` does have potential to break source in
 
 However we expect these cases will be uncommon, and can be disambiguated with parentheses or closures if needed.
 
-To accommodate the cases where source may be broken, `/.../` regex literals will be introduced in Swift 6 mode. However, projects may adopt the syntax earlier by passing the compiler flag `-enable-bare-slash-regex`. Note this does not affect the extended delimiter syntax `#/.../#`, which will be usable immediately.
+To accommodate the cases where source may be broken, `/.../` regex literals will be introduced in Swift 6 mode. However, projects may adopt the syntax earlier by passing the compiler flag `-enable-bare-slash-regex` or the [upcoming feature flag](0362-piecemeal-future-features.md) `BareSlashRegexLiterals`. Note this does not affect the extended delimiter syntax `#/.../#`, which will be usable immediately.
 
 ## Future Directions