# \[Returned for revision\] SE-0371: Isolated synchronous deinit

**URL:** <https://forums.swift.org/t/returned-for-revision-se-0371-isolated-synchronous-deinit/60060>\
**Category:** Announcements\
**Created:** [September 2, 2022, 3:39pm UTC](https://forums.swift.org/t/returned-for-revision-se-0371-isolated-synchronous-deinit/60060 "2022-09-02T15:39:55Z")\
**Posts on this page:** 1\
**Showing post:** 1

<div class="post-metadata">

**Author:** ![Jumhyn](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jumhyn/32/3891_2.png) [@Jumhyn](https://forums.swift.org/u/Jumhyn)\
**Post date:** [September 2, 2022, 3:39pm UTC](https://forums.swift.org/t/returned-for-revision-se-0371-isolated-synchronous-deinit/60060/1 "2022-09-02T15:39:55Z")

</div>

Hi all,

The [review](https://forums.swift.org/t/se-0371-isolated-synchronous-deinit/59754) for [SE-0371: "Isolated synchronous deinit"](https://github.com/apple/swift-evolution/blob/main/proposals/0371-isolated-synchronous-deinit.md) ran from August 18th to August 31st. The language workgroup has decided to return the proposal for revision.

Feedback was overall positive on solving the issue presented in the proposal, and there was no major disagreement around the semantics of the isolated `deinit`. However, there were some concerns around defaulting `deinit`s to being isolated and around the copying of task locals. Specifically, reviewers pointed out that defaulting `deinit` to isolated may introduce unnecessary hops (in addition to binary size and runtime costs), and that copying task locals was a potentially expensive operation that was not likely to be useful in practice. The workgroup did recognize, however, that there is value in having `deinit` receive a _consistent_ view of the task locals, rather than just receiving the task locals of whatever task happens to run the `deinit`.

There were also questions raised about how this feature might interact with a future, fully-fledged `deinit async` feature, and whether such a feature might subsume the need for special-case rules for isolated `deinit` by allowing us to align `init` and `deinit` isolation rules. The workgroup discussed these points but realizes that there is likely a lot of further design work that would go into the full `deinit async` feature, so it isn’t entirely clear whether or not it would be worth it to have a way to write an isolated `deinit` in the meantime.

For these reasons, the language workgroup has elected to request the following revisions:

- By default, `deinit` should behave the same as today, that is, it should be nonisolated and only able to access `Sendable` state. To achieve an isolated `deinit`, the user should have to opt-in explicitly. One syntax for this opt-in suggested in the review was `isolated deinit`.
- Task locals should not be copied for an isolated `deinit`. Instead, to ensure the `deinit` receives a consistent set of task locals, the task locals should be cleared before calling into the `deinit`.
- Inclusion of additional discussion around the future `deinit async` direction. The language workgroup is not certain whether it makes sense to delay the ability for `deinit` to access isolated state until the implementation of a significantly larger and more complex feature, but would still like to see a more thorough discussion of this future direction to help make the case that it is worth it to add isolated `deinit` _now_.

Once these revisions are made the language workgroup will run another review of the revised proposal.

Thank you for participating in Swift Evolution.

---

_[View the full topic](https://forums.swift.org/t/returned-for-revision-se-0371-isolated-synchronous-deinit/60060)._