# Deinit and MainActor

**URL:** <https://forums.swift.org/t/deinit-and-mainactor/50132>\
**Category:** Discussion\
**Tags:** concurrency, actors\
**Created:** [June 30, 2021, 12:10pm UTC](https://forums.swift.org/t/deinit-and-mainactor/50132 "2021-06-30T12:10:10Z")\
**Posts on this page:** 1\
**Showing post:** 23

<div class="post-metadata">

**Author:** ![inamiy](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/inamiy/32/45098_2.png) [@inamiy](https://forums.swift.org/u/inamiy)\
**Post date:** [June 16, 2022, 4:19am UTC](https://forums.swift.org/t/deinit-and-mainactor/50132/23 "2022-06-16T04:19:45Z")

</div>

> [@epam-gor-gyolchanyan](#):
>
> here's how I think it would work:  
> if a type has a `deinit async` implemented, then when the reference count reaches zero an implicit call to something like `object.deinit()` is replaced by `async { await object.deinit() }`.

I like this @epam-gor-gyolchanyan's idea, and having actor-isolated `deinit async` is probably a better solution than trying to capture all actor properties into a new task manually for clean up as @Douglas_Gregor mentioned, which is obviously getting difficult when actor has tons of internal properties:

> [@Douglas\_Gregor](#):
>
> If the right semantics for your actor is to schedule a task to run later to complete teardown, capture the stored property values you need into that new task and let the `deinit` finish synchronously. But the actor instance itself has to go away.

I also think `deinit async` is slightly better than having synchronous actor-isolated `deinit` (without async) since non-isolated `deinit` is preferred whenever possible, and it looks symmetric to how actor-initializer works (synchronous non-isolated `init` and isolated `init async`).

cf.

> [@Nickolas\_Pohilets](#):
>
> I was talking about synchronous `deinit`, but isolated in the actor. This is sufficient to solve the original problem of this thread.
> 
> Asynchronous `deinit` is a different topic, but it is also possible. Resurrection is a problem, but it is completely orthogonal to asyncronousity.

I don't know much about compiler-internal whether `deinit async` (or synchronous actor-isolated `deinit` for my 2nd favor) can be technically possible, but since accessing actor-isolated methods is difficult inside `deinit`, if Swift keeps providing non-isolated synchronous `deinit` only, I really wish there is at least some `magicalSelf` keyword to help Swift developers not do heavy lifting.

```swift
actor Foo {
    // Endless actor-isolated internal properties that can each call `cleanUp()`.
    var state1, state2, state3, ...

    // Clean up code used in many places, including `deinit`.
    func cleanUpAll() {
        state1.cleanUp()
        state2.cleanUp()
        ...
    }

    // Assume `deinit` is still non-isolated as is:
    deinit {
        // self.cleanUpAll() // ERROR: can't use actor-isolated method

        // BAD: Copy-pasting same code here is cumbersome. 
        Task.detached { [state1, state2, ...] in
            state1.cleanUp()
            state2.cleanUp()
            ...
        }

        // GOOD: Single line of code, and works like magic!
        magicalSelf.cleanUpAll()
    }
}

```

---

_[View the full topic](https://forums.swift.org/t/deinit-and-mainactor/50132)._