SE-0302: ConcurrentValue and @concurrent closures

[Douglas_Gregor]

@wtedst

Imagine someone adding a non- ConcurrentValue field to a struct, which suddenly breaks the conformance and renders the type unusable in a concurrent context, which they might have been relying on. What would they do if they don't understand what ConcurrentValue means? Most likely, if they become aware of this hack, they would just annotate it with @concurrent(unsafe) or make it conform to UnsafeConcurrentValue or whatever, totally bypassing the safeguard this proposal is attempting to provide (and I'm quite convinced that the "unsafe" wording is not something that would stop everybody). If they are careful enough to reconsider their choice, they would need to go through learning the semantics of ConcurrentValue anyways — but what happens here is that they suddenly also need to learn this implicit derivation algorithm and still audit their code for violation of these constraints.

I don't think your argument is really about the implicit ConcurrentValue. Your stated concern is that, on encountering a compiler error where a given type does not conform to ConcurrentValue, a user will use @concurrent(unsafe) or UnsafeConcurrentValue or whatever hammer we provide to silence the compiler error and move on. That problem is independent of whether the ConcurrentValue was written somewhere explicitly or not--and it's something we have to contend with whenever we provide an unsafe opt-out to a safety feature.

At some point, every Swift programmer is going to encounter ConcurrentValue and learn about it, and that's fine. However, Swift tries to follow the principle of progressive disclosure, and not inundate the developer with concerns up front when not necessary. There is a very large subset of Swift types for which the implicit ConcurrentValue conformance will always work, and we already nudge users toward modeling their data in terms of structs and enums of value types. Swift has always rewarded the use of value-semantic types like these with easier-to-reason-about code with localized mutation. The scenario you are discussing---adding a non-ConcurrentValue type such as a class instance to a struct or enum---will also break value semantics, so when doing so you're already in for some surprises from the basic Swift model.

Doug