Merge branch 'main' into tbkka-lifetime-dependency

Author: jckarter

CONTRIBUTING.md

@@ -1,13 +1,18 @@
-# Contributing to Swift Evolution
+# Welcome to the Swift community! 
 
-<https://www.swift.org/code-of-conduct/>
+Contributions to Swift are welcomed and encouraged! Please see the [Contributing to Swift guide](https://www.swift.org/contributing/) and check out the [structure of the community](https://www.swift.org/community/#community-structure).
 
-Pull requests that make minor editorial and administrative changes to this repository are always welcome, including fixing typos and grammar mistakes, repairing links, and maintaining document and repository metadata.
+To be a truly great community, Swift needs to welcome developers from all walks of life, with different backgrounds, and with a wide range of experience. A diverse and friendly community will have more great ideas, more unique perspectives, and produce more great code. We will work diligently to make the Swift community welcoming to everyone.
 
-Pull requests that add new proposals must follow the [Swift evolution process](process.md), including the proposal having first been pitched on the [evolution forums](https://forums.swift.org/c/evolution/pitches/5).
+To give clarity of what is expected of our members, Swift has adopted the code of conduct defined by the Contributor Covenant. This document is used across many open source communities, and we think it articulates our values well. For more, see the [Code of Conduct](https://www.swift.org/code-of-conduct/).
 
-Pull requests that make substantive changes to existing proposals should only be made with the permission of the proposal authors.  Substantive changes to a proposal in the Accepted or Rejected states are discouraged and require the approval of the appropriate evolution workgroup.  Substantive changes to a proposal in the Active Review state require the approval of the appropriate evolution workgroup and should be advertised in the review thread.
+## Contributing to Swift Evolution
 
-Pull requests that add or substantively change vision documents require the approval of the appropriate evolution workgroup.
+This repository is not your standard codebase. It houses Swift evolution proposals and related process documents, mostly composed of markdown and text files. Pull requests that make minor editorial and administrative changes are always welcome, including fixing typos and grammar mistakes, repairing links, and maintaining document and repository metadata. Other pull requests must follow the [Swift evolution process](process.md):
 
-Pull requests that substantively change the documented evolution process require the approval of the Core Team.
+- New proposals and substantive changes to existing proposals should be [pitched on the evolution forums](https://forums.swift.org/c/evolution/pitches/5) before a PR is opened here.
+- Substantive changes to existing proposals require the permission of the proposal authors.
+- Substantive changes to existing proposals require the approval of the appropriate evolution workgroup if the proposal is in an Active Review, Accepted, or Rejected state.
+- New vision documents and substantive changes to existing vision documents require the approval of the appropriate evolution workgroup.
+- Substantive changes to the evolution process require the approval of the Core Team.
+- Conversations about the substance of a proposal should be held in an appropriate forums thread rather than in PR comments.  This centralizes the discussion and allows more of the community to participate.

README.md

@@ -6,13 +6,14 @@ This repository tracks the ongoing evolution of the Swift programming language,
 
 ## Goals and Release Notes
 
-* [Swift project focus areas in 2023](https://forums.swift.org/t/swift-project-focus-areas-in-2023/61522)
-* [On the road to Swift 6](https://forums.swift.org/t/on-the-road-to-swift-6/32862)
+* [Swift Language focus areas heading into 2025](https://forums.swift.org/t/swift-language-focus-areas-heading-into-2025/76611)
 * [CHANGELOG](https://github.com/apple/swift/blob/main/CHANGELOG.md)
 
 | Version   | Announced                                                                | Released                                                     |
 | :-------- | :----------------------------------------------------------------------- | :----------------------------------------------------------- |
-| Swift 5.10 | [2023-08-23](https://forums.swift.org/t/swift-5-10-release-process/66911) |
+| Swift 6.1 | [2024-10-17](https://forums.swift.org/t/swift-6-1-release-process/75442) |
+| Swift 6.0 | [2024-02-22](https://forums.swift.org/t/swift-6-0-release-process/70220) | [2024-09-17](https://www.swift.org/blog/announcing-swift-6/) |
+| Swift 5.10 | [2023-08-23](https://forums.swift.org/t/swift-5-10-release-process/66911) | [2024-03-05](https://www.swift.org/blog/swift-5.10-released/) |
 | Swift 5.9 | [2023-03-06](https://forums.swift.org/t/swift-5-9-release-process/63557) | [2023-09-18](https://www.swift.org/blog/swift-5.9-released/) |
 | Swift 5.8 | [2022-11-19](https://forums.swift.org/t/swift-5-8-release-process/61540) | [2023-03-30](https://www.swift.org/blog/swift-5.8-released/) |
 | Swift 5.7 | [2022-03-29](https://forums.swift.org/t/swift-5-7-release-process/56316) | [2022-09-12](https://www.swift.org/blog/swift-5.7-released/) |

commonly_proposed.md

@@ -4,7 +4,7 @@ This is a list of changes to the Swift language that are frequently proposed but
 
 Additionally, proposals for out-of-scope changes will not be scheduled for review. The [readme file](README.md) identifies a list of priorities for the next major release of Swift, and the [dashboard](https://www.swift.org/swift-evolution/) includes a list of changes that have been rejected after a formal review.
 
-Several of the discussions below refer to "C family" languages. This is intended to mean the extended family of languages that resemble C at a syntactic level, such as C++, C#, Objective-C, Java, and Javascript. Swift embraces its C heritage. Where it deviates from other languages in the family, it does so because the feature was thought actively harmful (such as the pre/post-increment `++`) or to reduce needless clutter (such as `;` or parentheses in `if` statements).
+Several of the discussions below refer to "C family" languages. This is intended to mean the extended family of languages that resemble C at a syntactic level, such as C++, C#, Objective-C, Java, and JavaScript. Swift embraces its C heritage. Where it deviates from other languages in the family, it does so because the feature was thought actively harmful (such as the pre/post-increment `++`) or to reduce needless clutter (such as `;` or parentheses in `if` statements).
 
 ## Basic Syntax and Operators
 
@@ -29,7 +29,7 @@ Several of the discussions below refer to "C family" languages. This is intended
  * [Change closure literal syntax](https://forums.swift.org/t/streamlining-closures/487/3): Closure syntax in Swift has been carefully debated internally, and aspects of the design have strong motivations.  It is unlikely that we'll find something better, and any proposals to change it should have a very detailed understanding of the Swift grammar.
  * [Use pattern-matching in `if let` instead of optional-unwrapping](https://forums.swift.org/t/obsoleting-if-let/1301/4): We actually tried this and got a lot of negative feedback, for several reasons: (1) Most developers don't think about things in "pattern matching" terms, they think about "destructuring". (2) The vastly most common use case for `if let` is actually for optional matching, and this change made the common case more awkward. (3) This change increases the learning curve of Swift, changing pattern matching from being a concept that can be learned late to something that must be confronted early. (4) The current design of `if case` unifies "pattern matching" around the `case` keyword.  (5) If a developer unfamiliar with `if case` runs into one in some code, they can successfully search for it in a search engine or Stack Overflow.
  * [Remove or deprecate the force-unwrap operator `!`](https://forums.swift.org/t/moving-toward-deprecating-force-unwrap-from-swift/43455/82): Force-unwrap and force-try are legitimately useful parts of the language, and not just for source stability reasons. Therefore, proposals to deprecate or remove the force-unwrap operator (or `try!`), even in a mode enabled via compiler flag, will not be considered by the core team. Whether the Swift compiler should gain a more general "linting" capability to guide coding style remains a possible topic of discussion.
- * [Replace the `do`/`try`/`repeat` keywords with C++-style syntax](https://forums.swift.org/t/use-standard-syntax-instead-of-do-and-repeat/791/2): Swift's error handling approach is carefully designed to make it obvious to maintainers of code when a call can "throw" an error.  It is intentionally designed to be syntactically similar in some ways, but different in other key ways, to exception handling in other languages.  Its design is a careful balance that favors maintainers of code that uses errors, to make sure someone reading the code understands what can throw.  Before proposing a change to this system, please read the [Error Handling Rationale and Proposal](https://github.com/apple/swift/blob/master/docs/ErrorHandlingRationale.rst) in full to understand why the current design is the way it is, and be ready to explain why your changes would be worth unbalancing this design.
+ * [Replace the `do`/`try`/`repeat` keywords with C++-style syntax](https://forums.swift.org/t/use-standard-syntax-instead-of-do-and-repeat/791/2): Swift's error handling approach is carefully designed to make it obvious to maintainers of code when a call can "throw" an error.  It is intentionally designed to be syntactically similar in some ways, but different in other key ways, to exception handling in other languages.  Its design is a careful balance that favors maintainers of code that uses errors, to make sure someone reading the code understands what can throw.  Before proposing a change to this system, please read the [Error Handling Rationale and Proposal](https://github.com/swiftlang/swift/blob/main/docs/ErrorHandlingRationale.md) in full to understand why the current design is the way it is, and be ready to explain why your changes would be worth unbalancing this design.
 
 ## Miscellaneous
 

process.md

@@ -5,10 +5,16 @@ Swift is a powerful and intuitive programming language that is designed to make
 ## Scope
 
 The Swift evolution process covers all design changes, no matter how small, to the Swift language, its standard library, and the core tools necessary to build Swift programs.  This includes additions, removals, and changes to:
+
 - the features of the Swift language,
 - the public interface of the Swift standard library,
-- the configuration of the Swift compiler, and
-- the core tools of the Swift package ecosystem, including the configuration of the [Swift package manager](https://www.swift.org/package-manager/) and the design of its manifest files.
+- the configuration of the Swift compiler,
+- the core tools of the Swift package ecosystem, including the configuration of
+  the [Swift package manager](https://www.swift.org/package-manager/) and the
+  design of its manifest files, and
+- the public interfaces of the following libraries:
+  - [Swift Testing](https://github.com/swiftlang/swift-testing)
+  - [XCTest](https://github.com/swiftlang/swift-corelibs-xctest)
 
 The design of other tools, such as IDEs, debuggers, and documentation generators, is not covered by the evolution process.  The Core Team may create workgroups to guide and make recommendations about the development of these tools, but the output of those workgroups is not reviewed.
 
@@ -31,9 +37,12 @@ There is a natural tension between these two goals. Open evolution processes are
 
 The [Core Team](https://www.swift.org/community/#core-team) is responsible for the strategic direction of Swift.  The Core Team creates workgroups focused on specific parts of the project.  When the Core Team gives a workgroup authority over part of the evolution of the project, that workgroup is called an evolution workgroup.  Evolution workgroups manage the evolution process for proposals under their authority, working together with other workgroups as needed.
 
-Currently, there is only one evolution workgroup:
+Currently, there are three evolution workgroups:
 
-* The [Language Steering Group][language-steering-group] has authority over the evolution of the Swift language and its standard library.
+* The [Language Steering Group][language-steering-group] has authority over the evolution of the Swift language, its standard library, and any language configuration features of the Swift package manager.
+* The [Platform Steering Group][platform-steering-group] has authority over the evolution of all other features of the Swift package manager and its manifest files.
+* The [Testing Workgroup][testing-workgroup] has authority over the evolution of
+  the Swift Testing and Corelibs XCTest projects.
 
 The Core Team manages (or delegates) the evolution process for proposals outside these areas.  The Core Team also retains the power to override the evolution decisions of workgroups when necessary.
 
@@ -93,9 +102,12 @@ Please state explicitly whether you believe that the proposal should be accepted
 
 1. **Develop the proposal and implementation**
 
-   1. Expand the rough sketch into a formal proposal using the [proposal template](proposal-templates/0000-swift-template.md).
-   1. In the [swift-evolution repository][swift-evolution-repo], open a [draft pull request][draft-pr] that adds your proposal to the [proposals directory](/proposals).
-   1. Anounce the pull request on the forums and edit the root post to link out to the pull request.
+   1. Expand the rough sketch into a formal proposal using the
+      [relevant proposal template](#proposal-templates).
+   1. In the [swift-evolution repository][swift-evolution-repo], open a
+      [draft pull request][draft-pr] that adds your proposal to the appropriate
+      [proposal directory](#proposal-locations).
+   1. Announce the pull request on the forums and edit the root post to link out to the pull request.
    1. Refine the formal proposal in the open as you receive further feedback on the forums or the pull request.
       A ripe proposal is expected to address commentary from present and past
       discussions of the idea.
@@ -111,13 +123,13 @@ 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
       standard library internals or other non-public features.
       For more information about the kinds of changes that can be implemented in
-      the preview package, see [SE-0264](https://github.com/apple/swift-evolution/blob/main/proposals/0264-stdlib-preview-package.md).
+      the preview package, see [SE-0264](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0264-stdlib-preview-package.md).
 
 1. **Request a review**
 
@@ -128,6 +140,28 @@ Please state explicitly whether you believe that the proposal should be accepted
 
 [draft-pr]: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests#draft-pull-requests
 
+### Proposal templates
+
+When writing a formal proposal document, start with the most relevant template
+given the primary subject of the proposal:
+
+- Use the [Swift template][swift-template] for proposals concerning the Swift
+  language, compiler, or standard library.
+- Use the [Swift Package Manager template][swiftpm-template] for proposals
+  related to SwiftPM, including the design of its package manifest files and
+  command-line tools.
+- Use the [Swift Testing template][swift-testing-template] for proposals focused
+  on Swift Testing features or public interfaces.
+
+### Proposal locations
+
+When opening a pull request to add a new proposal to the
+[swift-evolution repository][swift-evolution-repo], place proposals which use
+the [Swift][swift-template] or [Swift Package Manager][swiftpm-template]
+templates in the top-level [proposals](/proposals) directory. Place proposals
+which use the newer [Swift Testing template][swift-testing-template] in the
+[proposals/testing](/proposals/testing) subdirectory.
+
 ## Review process
 
 The review process for a particular proposal begins when a member of
@@ -162,13 +196,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"])
 
@@ -205,12 +239,17 @@ A given proposal can be in one of several states:
   If the proposal's implementation spans multiple version numbers,
   write the version number for which the implementation will be complete.
 
-[swift-evolution-repo]: https://github.com/apple/swift-evolution  "Swift evolution repository"
-[swift-evolution-staging]: https://github.com/apple/swift-evolution-staging  "Swift evolution staging repository"
+[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
+[platform-steering-group]: https://www.swift.org/platform-steering-group
+[testing-workgroup]: https://www.swift.org/testing-workgroup  "Testing Workgroup page on Swift.org"
+[swift-template]: proposal-templates/0000-swift-template.md  "Swift proposal template"
+[swiftpm-template]: proposal-templates/0000-swiftpm-template.md  "Swift Package Manager proposal template"
+[swift-testing-template]: proposal-templates/0000-swift-testing-template.md  "Swift Testing proposal template"
 
 ## Review announcement
 
@@ -250,7 +289,7 @@ answer in your review:
 
 More information about the Swift evolution process is available at
 
-> <https://github.com/apple/swift-evolution/blob/main/process.md>
+> <https://github.com/swiftlang/swift-evolution/blob/main/process.md>
 
 Thank you,