Pitch #3: ConcurrentValue and @concurrent closures

[Chris_Lattner3 (Chris Lattner)]

@michelf

@cukr

Is there a list of what kinds of accesses have to be thread-safe? Getters? Setters? Calling a method? Calling a method that takes a parameter? Calling stuff defined in extensions? Passing the instance to an arbitrary function?

Personally I'd say all of the above. All public APIs involving a ConcurrentValue (I mean those vended by the same library as the type) should be thread-safe, unless they have "unsafe" in the name or take some other parameter of an "unsafe"-labeled type.

I agree. All public API should be usable across concurrency domains. I added this to the proposal to clarify the intent here, thanks!:

Type should conform to this protocol when the type is designed such that all of their public API is safe to use across concurrency domains. For example, if there are no public mutators, if public mutators are implemented with COW, or if they are implemented with internal locking or some other mechanism.

I also updated the proposal to explicitly discuss the inference rules for @concurrent on closure expressions and also to address the behavior of actor.self in closure expressions.

Thank you all for the feedback,

-Chris