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
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
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 access
Sendablestate. To achieve an isolated
deinit, the user should have to opt-in explicitly. One syntax for this opt-in suggested in the review was
- Task locals should not be copied for an isolated
deinit. Instead, to ensure the
deinitreceives a consistent set of task locals, the task locals should be cleared before calling into the
- Inclusion of additional discussion around the future
deinit asyncdirection. The language workgroup is not certain whether it makes sense to delay the ability for
deinitto 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
Once these revisions are made the language workgroup will run another review of the revised proposal.
Thank you for participating in Swift Evolution.