# Improved control over non-Sendable types in isolated contexts

**URL:** <https://forums.swift.org/t/improved-control-over-non-sendable-types-in-isolated-contexts/70608>\
**Category:** Discussion\
**Created:** [March 12, 2024, 1:42pm UTC](https://forums.swift.org/t/improved-control-over-non-sendable-types-in-isolated-contexts/70608 "2024-03-12T13:42:43Z")\
**Posts on this page:** 1\
**Showing post:** 2

<div class="post-metadata">

**Author:** ![Dmitriy\_Ignatyev](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/dmitriy_ignatyev/32/11340_2.png) [@Dmitriy\_Ignatyev](https://forums.swift.org/u/Dmitriy_Ignatyev)\
**Post date:** [March 28, 2024, 3:51pm UTC](https://forums.swift.org/t/improved-control-over-non-sendable-types-in-isolated-contexts/70608/2 "2024-03-28T15:51:06Z")

</div>

> [@vns](#):
>
> and throws us into a viral dependencies chain.

Hi, I fall into the same issues. My thoughts that as community we need more robust guidelines and best practices to address these issues, though. Seems that Swift 6 will also help to eliminate many of them.

> [@vns](#):
>
> ```swift
> // ok, still isolated
> await nonSendable.inc()
> 
> ```

`actor A` and `class B` performs their Tasks concurrently, so there will be concurrent calls to `nonSendable.inc()` and data race as a result.  
Can you please specify how `@isolated(local)` defined in `actor A` and `class B` will help prevent data races caused by concurrent calls to instance of class `NonSendable` (`nonSendable.inc()` method)?

There is also active review of `@isolated(any)` now: [SE-0431: `@isolated(any)` Function Types](https://forums.swift.org/t/se-0431-isolated-any-function-types/70939)

---

_[View the full topic](https://forums.swift.org/t/improved-control-over-non-sendable-types-in-isolated-contexts/70608)._