Merge branch 'main' into access-level-imports-2

Author: rjmccall

process.md

@@ -1,6 +1,6 @@
 # Swift Evolution Process
 
-Swift is a powerful and intuitive programming language that is designed to make writing and maintaining correct programs easier. Swift is growing and evolving, guided by a community-driven process referred to as the Swift evolution process. This document outlines the Swift evolution process and how a feature grows from a rough idea into something that can improve the Swift development experience for millions of programmers.
+Swift is a powerful and intuitive programming language that is designed to make writing and maintaining correct programs easier. Swift is growing and evolving, guided by a community-driven process referred to as the Swift evolution process, maintained by the [Language Steering Group][language-steering-group]. This document outlines the Swift evolution process and how a feature grows from a rough idea into something that can improve the Swift development experience for millions of programmers.
 
 ## Scope
 
@@ -33,7 +33,7 @@ The [Core Team](https://www.swift.org/community/#core-team) is responsible for t
 
 Currently, there is only one evolution workgroup:
 
-* The [Language Workgroup](https://www.swift.org/language-workgroup/#evolution-process) 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 and its standard library.
 
 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.
 
@@ -75,29 +75,64 @@ Please state explicitly whether you believe that the proposal should be accepted
 
 ## How to propose a change
 
-* **Check prior proposals**: many ideas come up frequently, and may either be in active discussion on the forums, or may have been discussed already and have joined the [Commonly Rejected Proposals](commonly_proposed.md) list. Please [search the forums](https://forums.swift.org/search) for context before proposing something new.
-* **Consider the goals of the upcoming Swift release**: Each major
-Swift release is focused on a [specific set of goals](README.md)
-described early in the release cycle. When proposing a change to
-Swift, please consider how your proposal fits in with the larger goals
-of the upcoming Swift release. Proposals that are clearly out of scope
-for the upcoming Swift release will not be brought up for review. If you can't resist discussing a proposal that you know is out of scope, please include the tag `[Out of scope]` in the subject.
-* **Socialize the idea**: propose a rough sketch of the idea in the ["pitches" section of the Swift forums](https://forums.swift.org/c/evolution/pitches), the problems it solves, what the solution looks like, etc., to gauge interest from the community.
-* **Develop the proposal**: expand the rough sketch into a complete proposal, using the [proposal template](proposal-templates/0000-swift-template.md), and continue to refine the proposal on the forums. Prototyping an implementation and its uses along with the proposal is *required* because it helps ensure both technical feasibility of the proposal as well as validating that the proposal solves the problems it is meant to solve.
-* **Request a review**: initiate a pull request to the [swift-evolution repository][swift-evolution-repo] to indicate to the Language Workgroup that you would like the proposal to be reviewed. When the proposal is sufficiently detailed and clear, and addresses feedback from earlier discussions of the idea, the pull request will be accepted. The proposal will be assigned a proposal number as well as a Language Workgroup member to manage the review.
-* **Address feedback**: in general, and especially [during the review period][proposal-status], be responsive to questions and feedback about the proposal.
+1. **Check prior proposals**
 
-## Preparing an implementation
+   Many ideas come up frequently, and may either be in active discussion on the forums, or may have been discussed already and have joined the [Commonly Rejected Proposals](commonly_proposed.md) list. Please [search the forums](https://forums.swift.org/search) for context before proposing something new.
 
-When you are ready to request a review, a pull request with an implementation is required in addition to your proposal. 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).
+1. **Consider the goals of the upcoming Swift release**
 
-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).
+   Each major Swift release is focused on a [specific set of goals](README.md)
+   described early in the release cycle. When proposing a change to
+   Swift, please consider how your proposal fits in with the larger goals
+   of the upcoming Swift release. Proposals that are clearly out of scope
+   for the upcoming Swift release will not be brought up for review. If you can't resist discussing a proposal that you know is out of scope, please include the tag `[Out of scope]` in the subject.
+
+1. **Socialize the idea**
+
+   Propose a rough sketch of the idea in the ["pitches" section of the Swift forums](https://forums.swift.org/c/evolution/pitches), the problems it solves, what the solution looks like, etc., to gauge interest from the community.
+
+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. 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.
+
+      Meanwhile, start working on an implementation.
+      Prototyping an implementation and its uses *alongside* the formal proposal
+      is important because it helps to determine an adequate scope, ensure
+      technical feasibility, and validate that the proposal lives up to
+      its motivation.
+
+      A pull request with a working implementation is *required* for the
+      proposal to be accepted for review.
+      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).
+
+      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).
+
+1. **Request a review**
+
+   Once you have a working implementation and believe the proposal is sufficiently detailed and clear, mark the draft pull request in the [swift-evolution repository][swift-evolution-repo] as ready for review to indicate to the appropriate evolution workgroup that you would like the proposal to be reviewed.
+
+> [!IMPORTANT]
+> In general, and especially [during the review period](#review-process), be responsive to questions and feedback about the proposal.
+
+[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
 
 ## Review process
 
 The review process for a particular proposal begins when a member of
-the Language Workgroup accepts a pull request of a new or updated proposal into
-the [swift-evolution repository][swift-evolution-repo]. That Language Workgroup
+the appropriate evolution workgroup accepts a pull request of a new or updated proposal into
+the [swift-evolution repository][swift-evolution-repo]. That
 member becomes the *review manager* for the proposal. The proposal
 is assigned a proposal number (if it is a new proposal), and then enters
 the review queue. If your proposal's accompanying implementation takes the form of a package, the review manager will merge your pull request into a new branch in the [swift-evolution-staging repository][swift-evolution-staging].
@@ -113,9 +148,9 @@ reviews. To avoid delays, it is important that the proposal authors be
 available to answer questions, address feedback, and clarify their
 intent during the review period.
 
-After the review has completed, the Language Workgroup will make a decision on
+After the review has completed, the managing evolution workgroup will make a decision on
 the proposal. The review manager is responsible for determining
-consensus among the Language Workgroup members, then reporting their decision
+consensus among the workgroup members, then reporting their decision
 to the proposal authors and forums. The review manager will
 update the proposal's state in the [swift-evolution
 repository][swift-evolution-repo] to reflect that decision.
@@ -173,8 +208,9 @@ A given proposal can be in one of several states:
 [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"
 [proposal-reviews]: https://forums.swift.org/c/evolution/proposal-reviews "'Proposal reviews' category of the Swift forums"
-[proposal-status]: https://apple.github.io/swift-evolution/
+[status-page]: https://apple.github.io/swift-evolution/
 [preview-package]: https://github.com/apple/swift-standard-library-preview/
+[language-steering-group]: https://www.swift.org/language-steering-group
 
 ## Review announcement
 

proposals/0165-dict.md

@@ -1,10 +1,10 @@
 # Dictionary & Set Enhancements
 
-- Proposal: [SE-0165](0165-dict.md)
-- Author: [Nate Cook](https://github.com/natecook1000)
-- Review Manager: [Ben Cohen](https://github.com/airspeedswift)
-- Status: **Implemented (Swift 4)**
-- Decision Notes: [Rationale][rationale]
+* Proposal: [SE-0165](0165-dict.md)
+* Author: [Nate Cook](https://github.com/natecook1000)
+* Review Manager: [Ben Cohen](https://github.com/airspeedswift)
+* Status: **Implemented (Swift 4)**
+* Decision Notes: [Rationale][rationale]
 
 ## Introduction
 

proposals/0220-count-where.md

@@ -3,17 +3,14 @@
 * Proposal: [SE-0220](0220-count-where.md)
 * Author: [Soroush Khanlou](https://github.com/khanlou)
 * Review Manager: [Ben Cohen](https://github.com/airspeedswift)
-* Status: **Active Review (July 18 – July 28, 2023)**
-* Previous status: **Accepted (2018-08-15) then Expired**
+* Status: **Accepted**
 * Implementation: [apple/swift#16099](https://github.com/apple/swift/pull/16099), [apple/swift#22289](https://github.com/apple/swift/pull/22289) (revert PR)
-* Previous Decision Notes: [Rationale](https://forums.swift.org/t/accepted-se-0220-count-where/15280), [Additional Commentary](https://forums.swift.org/t/require-parameter-names-when-referencing-to-functions/27048)
+* Review: ([first pitch](https://forums.swift.org/t/count-where-on-sequence/11186)) ([first review](https://forums.swift.org/t/se-0220-count-where/15048)) ([first acceptance](https://forums.swift.org/t/accepted-se-0220-count-where/15280)) ([second pitch](https://forums.swift.org/t/pitch-restore-count-where-from-se-0220/65859)) ([second review](https://forums.swift.org/t/refresh-review-se-0220-count-where/66235)) ([second acceptance](https://forums.swift.org/t/accepted-again-se-0220-count-where/66659))
 
 ## Introduction
 
 While Swift's `Sequence` models brings a lot of niceties that we didn't have access to in Objective-C, like `map` and `filter`, there are other useful operations on sequences that the standard library doesn't support yet. One current missing operation is  `count(where:)`, which counts the number of elements in a `Sequence` that pass some test.
 
-Swift-evolution thread: [`count(where:)` on Sequence](https://forums.swift.org/t/count-where-on-sequence/11186)
-
 ## Motivation
 
 Counting the number of objects that pass a test has a wide range of uses in many domains. However, Swift currently doesn't give its users a simple way to perform this operation. While the behavior can currently be approximated with a `filter` and a `count`, this approach creates an intermediate array which it immediately discards. This is a bit wasteful.