# Why does assumeIsolated() now require T: Sendable? **URL:** \ **Category:** Using Swift\ **Created:** [June 11, 2024, 1:31am UTC](https://forums.swift.org/t/why-does-assumeisolated-now-require-t-sendable/72344 "2024-06-11T01:31:05Z")\ **Posts on this page:** 1\ **Showing post:** 2
**Author:** ![xwu](https://avatars.discourse-cdn.com/v4/letter/x/b487fb/32.png) [@xwu](https://forums.swift.org/u/xwu)\ **Post date:** [June 11, 2024, 1:52am UTC](https://forums.swift.org/t/why-does-assumeisolated-now-require-t-sendable/72344/2 "2024-06-11T01:52:36Z")
This was discussed during the review of SE-0414: > [@SE-0414: Region Based Isolation](https://forums.swift.org/t/se-0414-region-based-isolation/68805/13): > > Would I be correct in saying that this proposal showcases an advantage of Swift using "concurrency domains" instead of threads as the basis of concurrency safety? If it had used threads instead, then non-Sendable object might use thread-local storage or some other thread-dependent runtime mechanism, and therefore might not be movable to a different region. But since "concurrency domains" are a construct entirely defined by the Swift language/compiler, we can make stronger guarantees about them, … > [@SE-0414: Region Based Isolation](https://forums.swift.org/t/se-0414-region-based-isolation/68805/21): > > This is a great point; I'd had this sticking in the back of my mind as a potential problem, and you're absolutely right to drag it out as something we need to deal with. The basic problem here can be summarized as follows: Region-based isolation adds a new capability in which non-Sendable values can be transferred between concurrency domains if they're currently in an independent region. There is an assumption in region-based isolation that non-isolated functions that have access to a non-Se… --- _[View the full topic](https://forums.swift.org/t/why-does-assumeisolated-now-require-t-sendable/72344)._