SE-0302: ConcurrentValue and @concurrent closures

[Chris_Lattner3 (Chris Lattner)]

@wtedst

Using an attribute would really be ideal, since having two different protocols also suggests different semantics, but really there's no semantic difference — it's indeed just an implementation detail.

Yes, making ConcurrentValue and UnsafeConcurrentValue both be attributes is initially attractive. The problem with this is that we'd need to reinvent something like conditional conformances to allow us to state that "arrays are CVs when their elements are". Directly leveraging the protocol design in Swift for this is convenient and avoids introducing a new form of complexity.

@xwu

struct MyNSPerson : @unchecked ConcurrentValue {

I was under the impression that, in terms of implementation work, parsing for this was already implemented (not sure whether in the main branch or in the S4TF only) for the previously discussed @memberwise conformance synthesis. But yes, it would add to the user-facing language.

Yes, I think you're right. After pondering on this more, I tend to think this is a good way to go - better than a separate UnsafeConcurrentValue protocol.

@Lantua

In the New @concurrent attribute for functions :

// Capturing a 'searchName' string is ok, because String conforms
// to ConcurrentValue. searchName is captured by value implicitly.
list = await contactList.filteredElements { $0.firstName==searchName }

Don't we need to put searchName in the capture list, or have it be a let variable? Neither is obvious in the context.

Yep, this got revised in the proposal for clarity, thanks!

-Chris