Merge branch 'main' into patch-4

Author: MahdiBM

README.md

@@ -11,7 +11,8 @@ This repository tracks the ongoing evolution of the Swift programming language,
 
 | Version   | Announced                                                                | Released                                                     |
 | :-------- | :----------------------------------------------------------------------- | :----------------------------------------------------------- |
-| Swift 6.1 | [2024-10-17](https://forums.swift.org/t/swift-6-1-release-process/75442) |
+| Swift 6.2 | [2025-03-08](https://forums.swift.org/t/swift-6-2-release-process/78371) | |
+| Swift 6.1 | [2024-10-17](https://forums.swift.org/t/swift-6-1-release-process/75442) | [2025-03-31](https://www.swift.org/blog/swift-6.1-released/) |
 | 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/) |

proposals/0439-trailing-comma-lists.md

@@ -43,7 +43,7 @@ let subsequences = numbers.split(
 
 ### The Language Evolved
 
-Back in 2016, a similar [proposal](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0084-trailing-commas.md) with a narrower scope was reviewed and rejected for Swift 3. Since that time, the language has evolved substantially that challenges the basis for rejection. The code style that "puts the terminating right parenthesis on a line following the arguments to that call" has been widely adopted by community, Swift standard library codebase, swift-format, docc documentation and Xcode. Therefore, not encouraging or endorsing this code style doesn't hold true anymore.
+Back in 2016, a similar [proposal](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0084-trailing-commas.md) with a narrower scope was reviewed and rejected for Swift 3. Since that time, the language has evolved substantially that challenges the basis for rejection. The code style that "puts the terminating right parenthesis on a line following the arguments to that call" has been widely adopted by community, Swift standard library codebase, swift-format, DocC documentation and Xcode. Therefore, not encouraging or endorsing this code style doesn't hold true anymore.
 
 The language has also seen the introduction of [parameter packs](https://github.com/apple/swift-evolution/blob/main/proposals/0393-parameter-packs.md), which enables APIs that are generic over variable numbers of type parameters, and code generation tools like plugins and macros that, with trailing comma support, wouldn't have to worry about a special condition for the last element when generating comma-separated lists.
 
@@ -267,16 +267,7 @@ if
 
 This particular case can be handled but, given how complex conditions can be, it's hard to conclude that there's absolutely no corner case where ambiguity can arise in currently valid code.
 
-Inheritance lists and generic `where` clauses can appear in protocol definitons where there's no clear delimiter, making it harder to disambiguate where the list ends.
-
-```swift
-protocol Foo {
-  associatedtype T:
-      P1,
-      P2, ❌ Expected type
-  ...
-}
-```
+Inheritance lists and generic `where` clauses can appear in protocol definitions where there's no clear delimiter, making it harder to disambiguate where the list ends.
 
 ```swift
 protocol Foo {

proposals/0456-stdlib-span-properties.md

@@ -3,9 +3,9 @@
 * Proposal: [SE-0456](0456-stdlib-span-properties.md)
 * Author: [Guillaume Lessard](https://github.com/glessard)
 * Review Manager: [Doug Gregor](https://github.com/DougGregor)
-* Status: **Accepted**
+* Status: **Implemented (Swift 6.2)**
 * Roadmap: [BufferView Roadmap](https://forums.swift.org/t/66211)
-* Implementation: [PR #78561](https://github.com/swiftlang/swift/pull/78561)
+* Implementation: [swift PR #78561](https://github.com/swiftlang/swift/pull/78561), [swift PR #80116](https://github.com/swiftlang/swift/pull/80116), [swift-foundation PR#1276](https://github.com/swiftlang/swift-foundation/pull/1276)
 * Review: ([pitch](https://forums.swift.org/t/76138)) ([review](https://forums.swift.org/t/se-0456-add-span-providing-properties-to-standard-library-types/77233)) ([acceptance](https://forums.swift.org/t/77684))
 
 [SE-0446]: https://github.com/swiftlang/swift-evolution/blob/main/proposals/0446-non-escapable.md

proposals/0465-nonescapable-stdlib-primitives.md

@@ -3,7 +3,7 @@
 * Proposal: [SE-0465](0465-nonescapable-stdlib-primitives.md)
 * Authors: [Karoy Lorentey](https://github.com/lorentey)
 * Review Manager: [Doug Gregor](https://github.com/douggregor)
-* Status: **Accepted**
+* Status: **Implemented (Swift 6.2)**
 * Roadmap: [Improving Swift performance predictability: ARC improvements and ownership control][Roadmap]
 * Implementation: https://github.com/swiftlang/swift/pull/73258
 * Review: ([Acceptance](https://forums.swift.org/t/accepted-se-0465-standard-library-primitives-for-nonescapable-type/78637)) ([Review](https://forums.swift.org/t/se-0465-standard-library-primitives-for-nonescapable-types/78310)) ([Pitch](https://forums.swift.org/t/pitch-nonescapable-standard-library-primitives/77253))

proposals/0467-MutableSpan.md

@@ -3,9 +3,9 @@
 * Proposal: [SE-0467](0467-MutableSpan.md)
 * Author: [Guillaume Lessard](https://github.com/glessard)
 * Review Manager: [Joe Groff](https://github.com/jckarter)
-* Status: **Accepted**
+* Status: **Implemented (Swift 6.2)**
 * Roadmap: [BufferView Roadmap](https://forums.swift.org/t/66211)
-* Implementation: "Future" target of [swift-collections](https://github.com/apple/swift-collections/tree/future)
+* Implementation: [PR #79650](https://github.com/swiftlang/swift/pull/79650), [PR #80517](https://github.com/swiftlang/swift/pull/80517)
 * Review: ([Pitch](https://forums.swift.org/t/pitch-mutablespan/77790)) ([Review](https://forums.swift.org/t/se-0467-mutablespan/78454)) ([Acceptance](https://forums.swift.org/t/accepted-se-0467-mutablespan/78875))
 
 [SE-0446]: https://github.com/swiftlang/swift-evolution/blob/main/proposals/0446-non-escapable.md

proposals/0468-async-stream-continuation-hashable-conformance.md

@@ -3,7 +3,7 @@
 * Proposal: [SE-0468](0468-async-stream-continuation-hashable-conformance.md)
 * Authors: [Mykola Pokhylets](https://github.com/nickolas-pohilets)
 * Review Manager: [Freddy Kellison-Linn](https://github.com/Jumhyn)
-* Status: **Accepted**
+* Status: **Implemented (Swift 6.2)**
 * Implementation: [swiftlang/swift#79457](https://github.com/swiftlang/swift/pull/79457)
 * Review: ([pitch](https://forums.swift.org/t/pitch-add-hashable-conformance-to-asyncstream-continuation/77897)) ([review](https://forums.swift.org/t/se-0468-hashable-conformance-for-async-throwing-stream-continuation/78487)) ([acceptance](https://forums.swift.org/t/accepted-se-0468-hashable-conformance-for-async-throwing-stream-continuation/79116))
 

proposals/0471-is-isolated-flow.png

@@ -3,8 +3,11 @@
 * Proposal: [SE-0472](0472-task-start-synchronously-on-caller-context.md)
 * Authors: [Konrad 'ktoso' Malawski](https://github.com/ktoso)
 * Review Manager: [Tony Allevato](https://github.com/allevato)
-* Status: **Accepted**
-* Implementation: https://github.com/swiftlang/swift/pull/79608
+* Status: **Implemented (Swift 6.2)**
+* Implementation:
+  * https://github.com/swiftlang/swift/pull/79608
+  * https://github.com/swiftlang/swift/pull/81428
+  * https://github.com/swiftlang/swift/pull/81572
 * Review: ([pitch](https://forums.swift.org/t/pitch-concurrency-starting-tasks-synchronously-from-caller-context/77960/)) ([first review](https://forums.swift.org/t/se-0472-starting-tasks-synchronously-from-caller-context/78883)) ([returned for revision](https://forums.swift.org/t/returned-for-revision-se-0472-starting-tasks-synchronously-from-caller-context/79311)) ([second review](https://forums.swift.org/t/second-review-se-0472-starting-tasks-synchronously-from-caller-context/79683)) ([acceptance](https://forums.swift.org/t/accepted-with-modifications-se-0472-starting-tasks-synchronously-from-caller-context/80037))
 
 ## Introduction

proposals/0472-task-start-synchronously-on-caller-context.md

@@ -3,10 +3,10 @@
 * Proposal: [SE-0474](0474-yielding-accessors.md)
 * Authors: [Ben Cohen](https://github.com/airspeedswift), [Nate Chandler](https://github.com/nate-chandler), [Joe Groff](https://github.com/jckarter/)
 * Review Manager: [Steve Canon](https://github.com/stephentyrone)
-* Status: **Active Review (April 8 ... April 22, 2025)**
+* Status: **Accepted**
 * Vision: [A Prospective Vision for Accessors in Swift](https://github.com/rjmccall/swift-evolution/blob/accessors-vision/visions/accessors.md)
 * Implementation: Partially available on main behind the frontend flag `-enable-experimental-feature CoroutineAccessors`
-* Review: ([pitch 1](https://forums.swift.org/t/modify-accessors/31872)), ([pitch 2](https://forums.swift.org/t/pitch-modify-and-read-accessors/75627)), ([pitch 3](https://forums.swift.org/t/pitch-3-yielding-coroutine-accessors/77956)), ([review](https://forums.swift.org/t/se-0474-yielding-accessors/79170))
+* Review: ([pitch 1](https://forums.swift.org/t/modify-accessors/31872)), ([pitch 2](https://forums.swift.org/t/pitch-modify-and-read-accessors/75627)), ([pitch 3](https://forums.swift.org/t/pitch-3-yielding-coroutine-accessors/77956)), ([review](https://forums.swift.org/t/se-0474-yielding-accessors/79170)), [Acceptance](https://forums.swift.org/t/accepted-se-0474-yielding-accessors/80273)
 
 ## Introduction
 
@@ -220,7 +220,7 @@ To fulfill such a requirement, the conformance must provide a getter, meaning it
 In practical terms, this means that the requirement cannot be witnessed by a stored property or a `yielding borrow` accessor when the result is of noncopyable type,[^2] since the storage of a stored property is owned by the containing aggregate and the result of a `yielding borrow` is owned by the suspended coroutine, and it would be necessary to copy to provide ownership to the caller.
 However, if the type of the `get` requirement is copyable, the compiler can synthesize the getter from the other accessor kinds by introducing copies as necessary.
 
-[^2]: While the compiler does currently accept such code currently, it does so by interpreting that `get` as a `yielding borrow`, which is a bug.
+[^2]: While the compiler does currently accept such code, it does so by interpreting that `get` as a `yielding borrow`, which is a bug.
 
 ### `yielding mutate`<a name="design-modify"/>
 

proposals/0474-yielding-accessors.md

@@ -3,9 +3,9 @@
 * Proposal: [SE-0475](0475-observed.md)
 * Authors: [Philippe Hausler](https://github.com/phausler)
 * Review Manager: [Freddy Kellison-Linn](https://github.com/Jumhyn)
-* Status: **Active Review (April 10 ... May 13, 2025)**
+* Status: **Accepted**
 * Implementation: https://github.com/swiftlang/swift/pull/79817
-* Review: ([pitch](https://forums.swift.org/t/pitch-transactional-observation-of-values/78315)) ([review](https://forums.swift.org/t/se-0475-transactional-observation-of-values/79224))
+* Review: ([pitch](https://forums.swift.org/t/pitch-transactional-observation-of-values/78315)) ([review](https://forums.swift.org/t/se-0475-transactional-observation-of-values/79224)) ([acceptance](https://forums.swift.org/t/accepted-se-0475-transactional-observation-of-values/80389))
 
 ## Introduction
 
@@ -103,7 +103,7 @@ that pet's name.
 
 ## Detailed design
 
-There a few behaviors that are prerequisites to understanding the requirements
+There are a few behaviors that are prerequisites to understanding the requirements
 of the actual design. These two key behaviors are how the model handles tearing
 and how the model handles sharing.
 
@@ -173,7 +173,7 @@ Task.detached {
 }
 ```
 
-In this case both tasks will get the same values upon the same events. This can 
+In this case both tasks will get consistently safe accessed values. This can 
 be achieved without needing an extra buffer since the suspension of each side of 
 the iteration are continuations resuming all together upon the accessor's 
 execution on the specified isolation. This facilitates subject-like behavior 
@@ -257,6 +257,12 @@ composition of potentially failable systems. Any thrown error will mean that the
 terminate with that given failure. Subsequent calls then to `next` on those 
 iterators will return `nil` - indicating that the iteration is complete. 
 
+The type `Observations` will conform to `AsyncSequence`. This means that it
+adheres to the cancellation behavior of other `AsyncSequence` types; if the task
+is cancelled then the iterator will return nil, and any time it becomes 
+terminal for any reason that sequence will remain terminal and continue returning nil. 
+Termination by cancellation however is independent for each instance. 
+
 ## Behavioral Notes
 
 There are a number of scenarios of iteration that can occur. These can range from production rate to iteration rate differentials to isolation differentials to concurrent iterations. Enumerating all possible combinations is of course not possible but the following explanations should illustrate some key usages. `Observations` does not make unsafe code somehow safe - the concepts of isolation protection or exclusive access are expected to be brought to the table by the types involved. It does however require the enforcements via Swift Concurrency particularly around the marking of the types and closures being required to be `Sendable`. The following examples will only illustrate well behaved types and avoid fully unsafe behavior that would lead to crashes because the types being used are circumventing that language safety.
@@ -351,7 +357,7 @@ The result of the observation may print the following output, but the primary pr
 3 3
 ```
 
-This case dropped the last value of the iteration because the accumulated differential exceeded the production; however the potentially confusing part here is that the sleep in the iterate competes with the scheduling in the emitter. This becomes clearer of a relationship when the boundaries of isolation are crossed.
+The last value is never observed because the program ends before it would be. If the program did not terminate then another value would be observed.
 
 Observations can be used across boundaries of concurrency. This is where the iteration is done on a different isolation than the mutations. The types however are accessed always in the isolation that the creation of the Observations closure is executed. This means that if the `Observations` instance is created on the main actor then the subsequent calls to the closure will be done on the main actor.