Hi all,
The review for SE-0371: "Isolated synchronous deinit" 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 deinits 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,
deinitshould behave the same as today, that is, it should be nonisolated and only able to accessSendablestate. To achieve an isolateddeinit, the user should have to opt-in explicitly. One syntax for this opt-in suggested in the review wasisolated deinit. - Task locals should not be copied for an isolated
deinit. Instead, to ensure thedeinitreceives a consistent set of task locals, the task locals should be cleared before calling into thedeinit. - Inclusion of additional discussion around the future
deinit asyncdirection. The language workgroup is not certain whether it makes sense to delay the ability fordeinitto 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 isolateddeinitnow.
Once these revisions are made the language workgroup will run another review of the revised proposal.
Thank you for participating in Swift Evolution.