SE-0302: ConcurrentValue and @concurrent closures

[cukr]

@Chris_Lattner3

This proposal is orthogonal to making global variable access safe. There are at least two different proposals to how to handle this (e.g. mine ), and both compose correctly with this proposal.

Thanks! Didn't realize that there will be other proposals that will make it safe.

@Douglas_Gregor

There are two reasons I disagree. The first is that this proposal is part of a larger arc for Swift Concurrency: it solves a necessary part of the problem of data races, but is not sufficient to solve all data races. Trying to solve all problems at once leads to proposals that are too large to meaningful digest or discuss.

I'm happy with problems being broken up into multiple proposals! I just noticed that the checks in the proposal are not sufficient to ensure safety, and wanted to know if there's something I'm missing. The first reply sounded like the safety wouldn't be introduced until long time into the future (swift 6 is often used as a hypothetical release when there are breaking changes, which I don't see happening any time soon). Now I know that the handrails will be reinforced before concurrency is out :)

@Douglas_Gregor

you're conflating a type-level statement (values of the type can be shared across concurrency domains) with a more global statement (every operation on the type is free of data races), and they need not be conflated.

In the pitch thread I asked what are the requirements for conforming to the ConcurrentValue protocol, and the answer was that all public API should be usable across concurrency domains

If that's not what "can be shared across concurrency domains" means, then could you tell me what does it mean? As far as I know values of all types can be shared across threads, as long as you don't perform any operations on them.

@Douglas_Gregor

we look to doing something with global variables specifically to address the issue.

I'm looking forward to it!