Merge branch 'main' into mutablespan

Author: jckarter

process.md

@@ -111,7 +111,7 @@ Please state explicitly whether you believe that the proposal should be accepted
       Proposals that can ship as part of the [Standard Library Preview package][preview-package]
       should be paired with a pull request against the [swift-evolution-staging repository][swift-evolution-staging].
       All other proposals should be paired with an implementation pull request
-      against the [main Swift repository](https://github.com/apple/swift).
+      against the [main Swift repository](https://github.com/swiftlang/swift).
 
       The preview package can accept new types, new protocols, and extensions to
       existing types and protocols that can be implemented without access to
@@ -162,13 +162,13 @@ flowchart LR
   %% <https://mermaid-js.github.io/>
 
   %% Nodes:
-  1{{"Awaiting\nreview"}}
-  2{{"Scheduled\nfor review"}}
-  3{"Active\nreview"}
-  4["Returned\nfor revision"]
+  1{{"Awaiting<br/>review"}}
+  2{{"Scheduled<br>for review"}}
+  3{"Active<br/>review"}
+  4["Returned<br/>for revision"]
   5(["Withdrawn"])
   6(["Rejected"])
-  7_8["Accepted\n(with revisions)"]
+  7_8["Accepted<br/>(with revisions)"]
   9[["Previewing"]]
   10(["Implemented"])
 
@@ -208,7 +208,7 @@ A given proposal can be in one of several states:
 [swift-evolution-repo]: https://github.com/swiftlang/swift-evolution  "Swift evolution repository"
 [swift-evolution-staging]: https://github.com/swiftlang/swift-evolution-staging  "Swift evolution staging repository"
 [proposal-reviews]: https://forums.swift.org/c/evolution/proposal-reviews "'Proposal reviews' category of the Swift forums"
-[status-page]: https://apple.github.io/swift-evolution/
+[status-page]: https://www.swift.org/swift-evolution
 [preview-package]: https://github.com/apple/swift-standard-library-preview/
 [language-steering-group]: https://www.swift.org/language-steering-group
 

proposal-templates/0000-swift-testing-template.md

@@ -0,0 +1,184 @@
+# Swift Testing Feature name
+
+* Proposal: [ST-NNNN](NNNN-filename.md)
+* Authors: [Author 1](https://github.com/author1), [Author 2](https://github.com/author2)
+* Status: **Awaiting implementation** or **Awaiting review**
+* Bug: _if applicable_ [swiftlang/swift-testing#NNNNN](https://github.com/swiftlang/swift-testing/issues/NNNNN)
+* Implementation: [swiftlang/swift-testing#NNNNN](https://github.com/swiftlang/swift-testing/pull/NNNNN)
+* Previous Proposal: _if applicable_ [ST-XXXX](XXXX-filename.md)
+* Previous Revision: _if applicable_ [1](https://github.com/swiftlang/swift-evolution/blob/...commit-ID.../proposals/testing/NNNN-filename.md)
+* Review: ([pitch](https://forums.swift.org/...))
+
+When filling out this template, you should delete or replace all of the text
+except for the section headers and the header fields above. For example, you
+should delete everything from this paragraph down to the Introduction section
+below.
+
+As a proposal author, you should fill out all of the header fields. Delete any
+header fields marked _if applicable_ that are not applicable to your proposal.
+
+When sharing a link to the proposal while it is still a PR, be sure to share a
+live link to the proposal, not an exact commit, so that readers will always see
+the latest version when you make changes. On GitHub, you can find this link by
+browsing the PR branch: from the PR page, click the "username wants to merge ...
+from username:my-branch-name" link and find the proposal file in that branch.
+
+`Status` should reflect the current implementation status while the proposal is
+still a PR. The proposal cannot be reviewed until an implementation is available,
+but early readers should see the correct status.
+
+`Bug` should be used when this proposal is fixing a bug with significant
+discussion in the bug report. It is not necessary to link bugs that do not
+contain significant discussion or that merely duplicate discussion linked
+somewhere else. Do not link bugs from private bug trackers.
+
+`Implementation` should link to the PR(s) implementing the feature. If the
+proposal has not been implemented yet, or if it simply codifies existing
+behavior, just say that. If the implementation has already been committed to the
+main branch (as an experimental feature or SPI), mention that. If the
+implementation is spread across multiple PRs, just link to the most important
+ones.
+
+`Previous Proposal` should be used when there is a specific line of succession
+between this proposal and another proposal. For example, this proposal might
+have been removed from a previous proposal so that it can be reviewed separately,
+or this proposal might supersede a previous proposal in some way that was felt
+to exceed the scope of a "revision". Include text briefly explaining the
+relationship, such as "Supersedes ST-1234" or "Extracted from ST-01234". If
+possible, link to a post explaining the relationship, such as a review decision
+that asked for part of the proposal to be split off. Otherwise, you can just
+link to the previous proposal.
+
+`Previous Revision` should be added after a major substantive revision of a
+proposal that has undergone review. It links to the previously reviewed revision.
+It is not necessary to add or update this field after minor editorial changes.
+
+`Review` is a history of all discussion threads about this proposal, in
+chronological order. Use these standardized link names: `pitch` `review`
+`revision` `acceptance` `rejection`. If there are multiple such threads, spell
+the ordinal out: `first pitch` `second review` etc.
+
+## Introduction
+
+A short description of what the feature is. Try to keep it to a single-paragraph
+"elevator pitch" so the reader understands what problem this proposal is
+addressing.
+
+## Motivation
+
+Describe the problems that this proposal seeks to address. If the problem is
+that some common pattern is currently hard to express, show how one can
+currently get a similar effect and describe its drawbacks. If it's completely
+new functionality that cannot be emulated, motivate why this new functionality
+would help Swift developers test their code more effectively.
+
+## Proposed solution
+
+Describe your solution to the problem. Provide examples and describe how they
+work. Show how your solution is better than current workarounds: is it cleaner,
+safer, or more efficient?
+
+This section doesn't have to be comprehensive. Focus on the most important parts
+of the proposal and make arguments about why the proposal is better than the
+status quo.
+
+## Detailed design
+
+Describe the design of the solution in detail. If it includes new API, show the
+full API and its documentation comments detailing what it does. If it involves
+new macro logic, describe the behavior changes and include a succinct example of
+the additions or modifications to the macro expansion code. The detail in this
+section should be sufficient for someone who is *not* one of the authors to be
+able to reasonably implement the feature.
+
+## Source compatibility
+
+Describe the impact of this proposal on source compatibility. As a general rule,
+all else being equal, test code that worked in previous releases of the testing
+library should work in new releases. That means both that it should continue to
+build and that it should continue to behave dynamically the same as it did
+before.
+
+This is not an absolute guarantee, and the testing library administrators will
+consider intentional compatibility breaks if their negative impact can be shown
+to be small and the current behavior is causing substantial problems in practice.
+
+For proposals that affect testing library API, consider the impact on existing
+clients. If clients provide a similar API, will type-checking find the right one?
+If the feature overloads an existing API, is it problematic that existing users
+of that API might start resolving to the new API?
+
+## Integration with supporting tools
+
+In this section, describe how this proposal affects tools which integrate with
+the testing library. Some features depend on supporting tools gaining awareness
+of the new feature for users to realize new benefits. Other features do not
+strictly require integration but bring improvement opportunities which are worth
+considering. Use this section to discuss any impact on tools.
+
+This section does need not to include details of how this proposal may be
+integrated with _specific_ tools, but it should consider the general ways that
+tools might support this feature and note any accompanying SPI intended for
+tools which are included in the implementation. Note that tools may evolve
+independently and have differing release schedules than the testing library, so
+special care should be taken to ensure compatibility across versions according
+to the needs of each tool.
+
+## Future directions
+
+Describe any interesting proposals that could build on this proposal in the
+future. This is especially important when these future directions inform the
+design of the proposal, for example by making sure an interface meant for tools
+integration can be extended to include additional information.
+
+The rest of the proposal should generally not talk about future directions
+except by referring to this section. It is important not to confuse reviewers
+about what is covered by this specific proposal. If there's a larger vision that
+needs to be explained in order to understand this proposal, consider starting a
+discussion thread on the forums to capture your broader thoughts.
+
+Avoid making affirmative statements in this section, such as "we will" or even
+"we should". Describe the proposals neutrally as possibilities to be considered
+in the future.
+
+Consider whether any of these future directions should really just be part of
+the current proposal. It's important to make focused, self-contained proposals
+that can be incrementally implemented and reviewed, but it's also good when
+proposals feel "complete" rather than leaving significant gaps in their design.
+An an example from the Swift project, when
+[SE-0193](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0193-cross-module-inlining-and-specialization.md)
+introduced the `@inlinable` attribute, it also included the `@usableFromInline`
+attribute so that declarations used in inlinable functions didn't have to be
+`public`. This was a relatively small addition to the proposal which avoided
+creating a serious usability problem for many adopters of `@inlinable`.
+
+## Alternatives considered
+
+Describe alternative approaches to addressing the same problem. This is an
+important part of most proposal documents. Reviewers are often familiar with
+other approaches prior to review and may have reasons to prefer them. This
+section is your first opportunity to try to convince them that your approach is
+the right one, and even if you don't fully succeed, you can help set the terms
+of the conversation and make the review a much more productive exchange of ideas.
+
+You should be fair about other proposals, but you do not have to be neutral;
+after all, you are specifically proposing something else. Describe any
+advantages these alternatives might have, but also be sure to explain the
+disadvantages that led you to prefer the approach in this proposal.
+
+You should update this section during the pitch phase to discuss any
+particularly interesting alternatives raised by the community. You do not need
+to list every idea raised during the pitch, just the ones you think raise points
+that are worth discussing. Of course, if you decide the alternative is more
+compelling than what's in the current proposal, you should change the main
+proposal; be sure to then discuss your previous proposal in this section and
+explain why the new idea is better.
+
+## Acknowledgments
+
+If significant changes or improvements suggested by members of the community
+were incorporated into the proposal as it developed, take a moment here to thank
+them for their contributions. This is a collaborative process, and everyone's
+input should receive recognition!
+
+Generally, you should not acknowledge anyone who is listed as a co-author.

proposals/0335-existential-any.md

@@ -62,7 +62,7 @@ Despite these significant and often undesirable implications, existential types
 
 ## Proposed solution
 
-I propose to make existential types syntactically explicit in the language using the `any` keyword. This proposal introduces the new syntax in the Swift 5 language mode, and this syntax should be required for existential types under the Swift 6 language mode.
+I propose to make existential types syntactically explicit in the language using the `any` keyword. This proposal introduces the new syntax in the Swift 5 language mode, and this syntax should be required for existential types under a future language mode.
 
 In Swift 5, anywhere that an existential type can be used today, the `any` keyword can be used to explicitly denote an existential type:
 
@@ -80,10 +80,10 @@ let pq1: P & Q = S() // 'P & Q' in this context is an existential type
 let pq2: any P & Q = S() // 'any P & Q' is an explicit existential type
 ```
 
-In Swift 6, existential types are required be explicitly spelled with `any`:
+In a future language mode, existential types are required to be explicitly spelled with `any`:
 
 ```swift
-// Swift 6 mode
+// Future language mode
 
 protocol P {}
 protocol Q {}
@@ -96,7 +96,7 @@ 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`.
+This behavior can be enabled in earlier language modes with the [upcoming feature flag](0362-piecemeal-future-features.md) `ExistentialAny`.
 
 ## Detailed design
 
@@ -192,11 +192,9 @@ func generic<T: AnotherP>(value: T) { ... }
 func generic<T: AnyP>(value: T) { ... } // error
 ```
 
-Once the `any` spelling is required under the Swift 6 language mode, a type alias to a plain protocol name is not a valid type witness for an associated type requirement; existential type witnesses must be explicit in the `typealias` with `any`:
+Once the `any` spelling is required under a future language mode, a type alias to a plain protocol name is not a valid type witness for an associated type requirement; existential type witnesses must be explicit in the `typealias` with `any`:
 
 ```swift
-// Swift 6 code
-
 protocol P {}
 
 protocol Requirements {
@@ -214,16 +212,16 @@ struct S2: Requirements {
 
 ## Source compatibility
 
-Enforcing that existential types use the `any` keyword will require a source change. To ease the migration, I propose to start allowing existential types to be spelled with `any` with the Swift 5.6 compiler, and require existential types to be spelled with `any` under the Swift 6 language mode. The old existential type syntax will continue to be supported under the Swift 5 language mode, and the transition to the new syntax is mechanical, so it can be performed automatically by a migrator.
+Enforcing that existential types use the `any` keyword will require a source change. To ease the migration, I propose to start allowing existential types to be spelled with `any` with the Swift 5.6 compiler, and require existential types to be spelled with `any` under a future language mode. The old existential type syntax will continue to be supported under the Swift 5 language mode, and the transition to the new syntax is mechanical, so it can be performed automatically by a migrator.
 
-[SE-0309 Unlock existentials for all protocols](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0309-unlock-existential-types-for-all-protocols.md) enables more code to be written using existential types. To minimize the amount of new code written that will become invalid in Swift 6, I propose requiring `any` immediately for protocols with `Self` and associated type requirements. This introduces an inconsistency for protocols under the Swift 5 language mode, but this inconsistency already exists today (because you cannot use certain protocols as existential types at all), and the syntax difference serves two purposes:
+[SE-0309 Unlock existentials for all protocols](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0309-unlock-existential-types-for-all-protocols.md) enables more code to be written using existential types. To minimize the amount of new code written that will become invalid under `ExistentialAny`, I propose requiring `any` immediately for protocols with `Self` and associated type requirements. This introduces an inconsistency for protocols under the Swift 5 language mode, but this inconsistency already exists today (because you cannot use certain protocols as existential types at all), and the syntax difference serves two purposes:
 
 1. It saves programmers time in the long run by preventing them from writing new code that will become invalid later.
-2. It communicates the existence of `any` and encourages programmers to start using it for other existential types before adopting Swift 6.
+2. It communicates the existence of `any` and encourages programmers to start using it for other existential types before adopting `ExistentialAny`.
 
-### Transitioning to `any` in Swift 6
+### Transitioning to `any`
 
-The new `any` syntax will be staged in over several major Swift releases. In the release where `any` is introduced, the compiler will not emit any warnings for the lack of `any` on existential types. After `any` is introduced, warnings will be added to guide programmers toward the new syntax. Finally, these warnings can become errors, or [plain protocol names can be repurposed](#re-purposing-the-plain-protocol-name), in Swift 6.
+The new `any` syntax will be staged in over several major Swift releases. In the release where `any` is introduced, the compiler will not emit diagnostics for the lack of `any` on existential types, save for the aforementioned cases. After `any` is introduced, warnings will be added to guide programmers toward the new syntax. Finally, a missing `any` will become an unconditional error, or [plain protocol names may be repurposed](#re-purposing-the-plain-protocol-name) — in Swift 6 or a later language mode.
 
 ## Effect on ABI stability
 

proposals/0371-isolated-synchronous-deinit.md

@@ -3,7 +3,7 @@
 * Proposal: [SE-0371](0371-isolated-synchronous-deinit.md)
 * Author: [Mykola Pokhylets](https://github.com/nickolas-pohilets)
 * Review Manager: [Frederick Kellison-Linn](https://github.com/jumhyn)
-* Status: **Implemented (Swift 6.1)**
+* Status: **Implemented (Swift 6.2)**
 * Implementation: [apple/swift#60057](https://github.com/apple/swift/pull/60057)
 * Review: ([first pitch](https://forums.swift.org/t/isolated-synchronous-deinit/58177)) ([first review](https://forums.swift.org/t/se-0371-isolated-synchronous-deinit/59754)) ([returned for revision](https://forums.swift.org/t/returned-for-revision-se-0371-isolated-synchronous-deinit/60060)) ([discussion](https://forums.swift.org/t/isolated-synchronous-deinit-2/62565)) ([second pitch](https://forums.swift.org/t/pitch-2-se-0371-isolated-async-deinit/64836)) ([sub-pitch](https://forums.swift.org/t/sub-pitch-task-local-values-in-isolated-synchronous-deinit-and-async-deinit/70060)) ([second review](https://forums.swift.org/t/second-review-se-0371-isolated-synchronous-deinit/73406)) ([accepted with modifications](https://forums.swift.org/t/accepted-with-modifications-se-0371-isolated-synchronous-deinit/74042))
 

proposals/0430-transferring-parameters-and-results.md

@@ -390,18 +390,12 @@ the callee. Unlike `consuming` parameters, `sending` parameters do not
 have no-implicit-copying semantics.
 
 To opt into no-implicit-copying semantics or to change the default ownership
-convention, `sending` may also be paired with an explicit `consuming` or
-`borrowing` ownership modifier:
+convention, `sending` may also be paired with an explicit `consuming` ownership modifier:
 
 ```swift
 func sendingConsuming(_ x: consuming sending T) { ... }
-func sendingBorrowing(_ x: borrowing sending T) { ... }
 ```
 
-Note that an explicit `borrowing` annotation always implies no-implicit-copying,
-so there is no way to change the default ownership convention of a
-`sending` parameter without also opting into no-implicit-copying semantics.
-
 ### Adoption in the Concurrency library
 
 There are several APIs in the concurrency library that send a parameter across