# 'inout sending' parameter cannot be task-isolated at end of function

**URL:** <https://forums.swift.org/t/inout-sending-parameter-cannot-be-task-isolated-at-end-of-function/80144>\
**Category:** Using Swift\
**Tags:** concurrency\
**Created:** [May 26, 2025, 8:43pm UTC](https://forums.swift.org/t/inout-sending-parameter-cannot-be-task-isolated-at-end-of-function/80144 "2025-05-26T20:43:37Z")\
**Posts on this page:** 1\
**Showing post:** 2

<div class="post-metadata">

**Author:** ![jamieQ](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jamieq/32/5117_2.png) [@jamieQ](https://forums.swift.org/u/jamieQ)\
**Post date:** [May 27, 2025, 12:23am UTC](https://forums.swift.org/t/inout-sending-parameter-cannot-be-task-isolated-at-end-of-function/80144/2 "2025-05-27T00:23:32Z")

</div>

i think the 'spirit' of this diagnostic is to deal with the fact that a `Mutex` can be populated with a non-Sendable value, but in order to do so it must be known to be in a 'disconnected' isolation region (i.e. is a `sending` value). since Mutex grants 'Sendability' to its contents, it must ensure that any subsequent changes to its contents do not alias non-Sendable values from other isolation regions.

as an simplified example, consider:

```swift
// non-Sendable type
class NS {}

final class C: Sendable {
    let lock = Mutex(NS()) // okay to init since the initial value isn't in any isolation region

    func setValue(_ v: NS) {
        lock.withLock { existing in
            // not okay to assign b/c `v` could have come from another isolation
            // region so could introduce a data race
            existing = v
        } // 🛑
    }
}

```

i feel like what you're 'supposed' to do in this circumstance is ensure the new value being assigned is also known to the compiler to be `sending`. AFAIK however, this for some reason still doesn't work currently (see a similar thread [here](https://forums.swift.org/t/mutex-error/76653)).

---

_[View the full topic](https://forums.swift.org/t/inout-sending-parameter-cannot-be-task-isolated-at-end-of-function/80144)._