# Preventing Data Races in the Swift Concurrency Model

**URL:** <https://forums.swift.org/t/preventing-data-races-in-the-swift-concurrency-model/43175>\
**Category:** Discussion\
**Created:** [December 20, 2020, 6:55am UTC](https://forums.swift.org/t/preventing-data-races-in-the-swift-concurrency-model/43175 "2020-12-20T06:55:28Z")\
**Posts on this page:** 1\
**Showing post:** 14

<div class="post-metadata">

**Author:** ![Douglas\_Gregor](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/douglas_gregor/32/1362_2.png) [@Douglas\_Gregor](https://forums.swift.org/u/Douglas_Gregor)\
**Post date:** [December 23, 2020, 6:00am UTC](https://forums.swift.org/t/preventing-data-races-in-the-swift-concurrency-model/43175/14 "2020-12-23T06:00:55Z")

</div>

> [@Joe\_Groff](#):
>
> Rather than talk about `let` s specifically, I think the properties you ascribe need to be discussed as applying to _values_ more generally, since they also apply to temporaries, arguments, returns, and such. They only apply to `let` s insomuch as a `let` binding only ever has one value once it's been bound.

Yes, I think you're right about that. I end up talking about parameters/results/variables/etc. when it's really about the values. Then `let` vs. `var` is about whether the value at that memory location can change.

> [@Joe\_Groff](#):
>
> ou say that there are "several general classes of such types", but I think that's an overcomplication. There's one specific property we're looking for in a value to say that it's sharable—does it not contain references to unsynchronized shared mutable state, transitively?

Yes, that's a good generalization!

> [@Joe\_Groff](#):
>
> Other languages like Pony use reference capabilities as a way of enforcing these rules at the granularity of individual references. We're making an explicit choice here to instead enforce the property at data type granularity instead.

Right, and maybe-some-time-in-the-future we get some kinds of types that are uniquely-referenced so we know they aren't ever actually shared.

> [@Joe\_Groff](#):
>
> As a type trait, I'm not sure it makes sense to refer to `ActorSendable` / `Shar[e]able` as a protocol—it has no formal requirements, and you can't really retroactively conform a type to it, and we wouldn't want becoming sharable to induce a witness table or other ABI changes that normal protocol conformances do.

I [brought this up](https://forums.swift.org/t/pitch-2-protocol-based-actor-isolation/42123/27) over in the protocol-based actor isolation pitch. I think we want a special kind of marker protocol that has no runtime footprint, and have an idea of how it might work.

Doug

---

_[View the full topic](https://forums.swift.org/t/preventing-data-races-in-the-swift-concurrency-model/43175)._