I shared the feedback already in the previous thread: Deinit and MainActor - #25 by ktoso
Agreed with John that we'd want opting "in" here; There may be plenty user-defined initializers which may be fine nonisolated, and by allowing deinit async it fits the same "opt into isolation" as init async does.
Worth considering still if isolated deinit is a thing or not... but we so far don't have such spelling anywhere, and rather use async to get isolation in initializers; and methods are the opposite, always isolated and opting out with nonisolated, as such deinit feels closer to deinit.
Re future directions: Clearing task local values
I believe it'd potentially risky/bad to just inherit some random values here so we do have to clear. But I believe you'll need to create a new task to run these cleanups anyway so it can (should?!) be detached. It seems pretty bad if we can get "arbitrary" context here. I don't think the task here is a child task, so there's no barrier needed to be written into the task locals list -- and since it's an unstructured task, we can not copy the locals and that's it.
Pending question on if it's worth trying to reuse/pool tasks for those deinits if they are indeed unstructured; rather than re-creating/allocating new tasks for every deinit hm.