[Returned for Revision] SE-0302: ConcurrentValue and @concurrent closures

John_McCall · 2021-03-03T03:39:15.787Z

The first review of SE-0302 ran from February 19th until yesterday. Reviewers were generally strongly positive about the basic ideas behind the proposal, but they had a number of significant reservations and suggested improvements. The Core Team discussed this feedback with the authors and reached several conclusions:

Several community members didn't like the proposed names of either the protocol (ConcurrentValue) or the function modifier (@concurrent). After some discussion, the authors have agreed to change these names to Sendable and @sendable. This name is a somewhat-established term of art, most prominently used in Rust for this same purpose. The Core Team invites feedback about this new name.
Several community members didn't like the use of a second UnsafeConcurrentValue protocol to add an unverified conformance, and consensus emerged in the review thread that this ought to be an attribute "on the conformance" (that is, immediately prior to the protocol name in a protocol lis). The authors have agreed to make this change using the spelling @unchecked:
```
extension NSWindow: @unchecked Sendable {}
```
Several community members expressed concern about the breadth of unchecked-ness in unchecked conformances. Unchecked conformances in the current proposal disable all checking of properties. In cases where the programmer knows that an unchecked conformance is actually safe because there are special restrictions on a particular set of properties (e.g., they are accessed only from a special thread, or only under a lock), it would be better to mark just those properties as unchecked, avoiding bugs where additional, unrestricted properties are added later but have non-Sendable type. Were this technique widely used, it would also resist the tendency for programmers to unthinkingly apply unchecked conformances just to silence the compiler. The Core Team seems the value in this idea but feels it is acceptable to consider it as a follow-up proposal, where it can be considered in conjunction with previously-pitched ideas like the UnsafeTransfer wrapper type.
Several community members expressed serious concerns about the annotation burden of adding the Sendable conformance to lots of different types. The Core Team agrees, and we would like to reduce this burden as much as possible. However, we are very reluctant to make the conformance implicit for public types, since this would create an easy source-compatibility and maybe even binary-compatibility trap. Therefore, we would like to pursue making the conformance implicit only for internal and private types, and otherwise requiring an annotation. We understand that this may still create a substantial annotation burden for library authors and for developers who have split their projects into multiple modules, and we are interested in ideas that can help improve these cases incrementally.

SE-0302 is accepted in its basic approach. It will be revised according to the above decisions, and the community will have an opportunity to review the result shortly. We ask that reviewers focus on just the changed aspects of the proposal, unless they feel that something important was missed in the first review.

Thank you for helping to make Swift a better language.

John McCall
Review Manager

John_McCall · 2021-03-03T03:55:04.737Z

I have opened a thread for the second review; please discuss these changes there.

John_McCall · 2021-03-03T03:55:08.499Z