# Why is a Task closure defined in an Actor's method nonisolated?

**URL:** <https://forums.swift.org/t/why-is-a-task-closure-defined-in-an-actors-method-nonisolated/84967>\
**Category:** Using Swift\
**Tags:** concurrency\
**Created:** [February 25, 2026, 3:32am UTC](https://forums.swift.org/t/why-is-a-task-closure-defined-in-an-actors-method-nonisolated/84967 "2026-02-25T03:32:28Z")\
**Posts on this page:** 1\
**Showing post:** 17

<div class="post-metadata">

**Author:** ![NotTheNHK](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/notthenhk/32/43199_2.png) [@NotTheNHK](https://forums.swift.org/u/NotTheNHK)\
**Post date:** [March 4, 2026, 4:56pm UTC](https://forums.swift.org/t/why-is-a-task-closure-defined-in-an-actors-method-nonisolated/84967/17 "2026-03-04T16:56:51Z")

</div>

That seems to be a bug. The interaction between `#isolation`, `nonisolated(nonsending)`, and Swift 5 causes `#isolation` to erroneously assume that the actor passed in from `nonisolated(nonsending)` represents the function’s static isolation. In contrast, Swift 6 correctly determines that they are all statically `nonisolated`. `#isolation` represents static isolation, whereas `nonisolated(nonsending)` represents dynamic isolation, or more precisely the executor on which the function should execute at runtime. However, the same erroneous behavior (in my opinion) appears in the devsnapshot and nightly builds. Perhaps I am misunderstanding something, but if that is true then I am quite confused.

cc @jamieQ@ktoso

---

_[View the full topic](https://forums.swift.org/t/why-is-a-task-closure-defined-in-an-actors-method-nonisolated/84967)._