|
5 | 5 | * Review Manager: [Ben Cohen](https://github.com/airspeedswift)
|
6 | 6 | * Status: **Implemented (Swift 5.5)** [Acceptance post](https://forums.swift.org/t/accepted-with-modifications-se-0304-structured-concurrency/51850)
|
7 | 7 | * Implementation: Available in [recent `main` snapshots](https://swift.org/download/#snapshots) behind the flag `-Xfrontend -enable-experimental-concurrency`
|
| 8 | +* Review: ([first pitch](https://forums.swift.org/t/concurrency-structured-concurrency/41622)) ([second pitch](https://forums.swift.org/t/pitch-2-structured-concurrency/43452)) ([third pitch](https://forums.swift.org/t/pitch-3-structured-concurrency/44496)) ([first review](https://forums.swift.org/t/se-0304-structured-concurrency/45314)) ([second review](https://forums.swift.org/t/se-0304-2nd-review-structured-concurrency/47217)) ([third review](https://forums.swift.org/t/se-0304-3rd-review-structured-concurrency/48847)) ([fourth review](https://forums.swift.org/t/se-0304-4th-review-structured-concurrency/50281)) ([acceptance](https://forums.swift.org/t/accepted-with-modifications-se-0304-structured-concurrency/51850)) ([revision](https://forums.swift.org/t/accepted-with-modifications-se-0304-structured-concurrency/51850/9)) |
| 9 | +* Previous revisions: ([first review](https://github.com/swiftlang/swift-evolution/blob/9b5e0cbd552b4c8b570aedcb94c0cb72b9f591b0/proposals/0304-structured-concurrency.md)) ([second review](https://github.com/swiftlang/swift-evolution/blob/3defec78bc3f7cbbc9a14f69511397d27899244d/proposals/0304-structured-concurrency.md)) ([third review](https://github.com/swiftlang/swift-evolution/blob/a0faeabd6718ba99865a940a085927a69494fe94/proposals/0304-structured-concurrency.md)) ([fourth review](https://github.com/swiftlang/swift-evolution/blob/2e9eda9f67ae7aabd89ea17baadd32affa416843/proposals/0304-structured-concurrency.md)) ([as accepted](https://github.com/swiftlang/swift-evolution/blob/c2f363236520589ab94ef91a1419e06f39346133/proposals/0304-structured-concurrency.md)) |
8 | 10 |
|
9 | 11 | ## Table of contents
|
10 | 12 |
|
@@ -1051,7 +1053,6 @@ func withTaskGroup<ChildTaskResult: Sendable, GroupResult>(
|
1051 | 1053 | /// This is achieved in the following way:
|
1052 | 1054 | /// - if the body returns normally:
|
1053 | 1055 | /// - the group will await any not yet complete tasks,
|
1054 |
| -/// - if any of those tasks throws, the remaining tasks will be cancelled, |
1055 | 1056 | /// - once the `withTaskGroup` returns the group is guaranteed to be empty.
|
1056 | 1057 | /// - if the body throws:
|
1057 | 1058 | /// - all tasks remaining in the group will be automatically cancelled.
|
@@ -1604,3 +1605,7 @@ Initially the `group.addTask` operation was designed with the idea of being an a
|
1604 | 1605 | This was not implemented nor is it clear how efficient and meaningful this form of back-pressure really would be. A naive version of these semantics is possible to implement by balancing pending and completed task counts in the group by plain variables, so removing this implementation does not prevent developers from implementing such "width limited" operations per se.
|
1605 | 1606 |
|
1606 | 1607 | The way to back-pressure submissions should also be considered in terms of how it relates to async let and general task creation mechanisms, not only groups. We have not figured this out completely, and rather than introduce an not-implemented API which may or may not have the right shape, for now we decided to punt on this feature until we know precisely if and how to apply this style of back-pressure on creating tasks throughout the system.
|
| 1608 | + |
| 1609 | +## Proposal history |
| 1610 | + |
| 1611 | +When this proposal was originally accepted, the description of `withThrowingTaskGroup` stated that any remaining tasks in the group will be cancelled if any task throws after the body function returns normally. This behavior was never implemented; throws from tasks are ignored in this state. By the time this discrepancy was detected, several years had passed, and the Language Steering Group decided that restoring the proposed behavior (if desired) would require a new proposal. This document has been revised to reflect the implemented behavior. |
0 commit comments