# Understanding how Task handles non Sendable captures

**URL:** <https://forums.swift.org/t/understanding-how-task-handles-non-sendable-captures/68585>\
**Category:** Using Swift\
**Created:** [November 22, 2023, 2:51pm UTC](https://forums.swift.org/t/understanding-how-task-handles-non-sendable-captures/68585 "2023-11-22T14:51:39Z")\
**Posts on this page:** 1\
**Showing post:** 5

<div class="post-metadata">

**Author:** ![ole](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/ole/32/18720_2.png) [@ole](https://forums.swift.org/u/ole)\
**Post date:** [December 26, 2023, 11:37am UTC](https://forums.swift.org/t/understanding-how-task-handles-non-sendable-captures/68585/5 "2023-12-26T11:37:19Z")

</div>

> [@wadetregaskis](#):
>
> `MyClass` as a class has no isolation. So your spawned task will inherit whatever the isolation context is from further up the callstack, whenever `doSomeStuff` is called.

I don’t think this is true. As far as I know, `Task`'s actor context inheritance is strictly _lexical_, i.e. it only depends on the annotations of the enclosing function (and enclosing type) at the call site, _not_ from where that function has been called.

In other words, we _know_ that the `Task { … }` in @mattie’s example does not inherit any actor isolation and thus runs on the global concurrent executor, because neither the containing function nor the enclosing class are annotated with a global actor).

Source: @Douglas_Gregor in [SE-0304 (4th review): Structured Concurrency - #36 by Douglas\_Gregor](https://forums.swift.org/t/se-0304-4th-review-structured-concurrency/50281/36) ("It's the lexical context.") (This was during the concurrency review process, but I don't believe the rules changed later.)

---

_[View the full topic](https://forums.swift.org/t/understanding-how-task-handles-non-sendable-captures/68585)._