# Isolated synchronous deinit

**URL:** <https://forums.swift.org/t/isolated-synchronous-deinit/58177>\
**Category:** Pitches\
**Created:** [June 16, 2022, 4:42pm UTC](https://forums.swift.org/t/isolated-synchronous-deinit/58177 "2022-06-16T16:42:59Z")\
**Posts on this page:** 1\
**Showing post:** 7

<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 17, 2022, 1:52pm UTC](https://forums.swift.org/t/isolated-synchronous-deinit/58177/7 "2022-06-17T13:52:13Z")

</div>

+1 for opt-in `deinit async` as I previously commented in:

> [@Deinit and MainActor](https://forums.swift.org/t/deinit-and-mainactor/50132/23):
>
> 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: 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 ho…

And in my opinion:

> [@Nickolas\_Pohilets](#):
>
> Note that proposal does not generate isolated deinit if there is no explicit deinit. Which in my experience is the most common case. This kinda serves as an opt-in mechanism.

"Non-isolated `deinit` when code is not written" will mislead developers when they just want to write a debug-print to observe when actor instance actually gets deallocated.

```swift
// Assume this is implicit isolated deinit.
deinit {
    // This printing may be called slower than non-isolated deinit.
    // (Also, thread printing will get changed which might also be tricky)
    print("deinit in \(Thread.current)") 
}

```

---

_[View the full topic](https://forums.swift.org/t/isolated-synchronous-deinit/58177)._