Hello Swift community,
The second review of SE-0371: Isolated synchronous deinit concluded on August 6th, 2024. The Language Steering Group has decided to accept the proposal with one modification: task locals should be consistently cleared when entering an isolated deinit rather than the proposed behavior of doing nothing to the task locals and making no documented promises about the behavior.
Reviews of the proposal were somewhat mixed. While many had run into deinit-related roadblocks while adopting the Swift 6 language mode and were supportive of the proposed solution, others raised deep discomfort with the dangers of introducing unstructured work scheduled at deinit time (as is necessary when the last reference to an object with an isolated deinit is dropped from outside the relevant isolation domain). While deinit has its own issues with introducing 'invisible' work related to lifetime management, reviewers pointed out that running resource reclamation asyncronously could even more easily result in indefinitely deferred work under load, and potentially be a vector for denial-of-service attacks in adversarial cases.
The LSG discussed this concern thoroughly, but did not believe that it rose to the level where it justified intentionally limiting the composition of deinit with the rest of the concurrency system; the Group agreed that the current state of affairs presents a bit of a usability cliff when trying to adapt systems which make use of deinit to Swift Concurrency. Moreover, since the feature is opt-in (as requested by the LSG after the prior review), code bases which need to take special care around lifetime management are free to lint against the use of isolated deinit to encourage caution around its use or outright ban it.
Other reviewers suggested that the syntax could be 'salted' to make it a bit more obscure or scary, e.g., @unstructured isolated deinit or similar. The LSG did not feel that is was necessary to pessimize the spelling of this feature to discourage its use, and that the potential pitfalls and failure modes were unlikely to be sufficiently communicated by choosing the 'right' set of keywords in source. Rather, the Group agreed with reviewers that the implications of adopting isolated deinit should be spelled out clearly in documentation, and that looking up isolated deinit would likely be sufficient for users who wish to understand the feature in more depth.
Lastly, on the topic of task locals, the LSG agreed with reviewers who expressed that the approach of 'make no promises' was likely to result in users inadvertently relying on implementation details which would turn out to be difficult to change later, and so decided to adopt the consistent rule that task locals will always be cleared when entering an isolated deinit.
As always, thank you to everyone who participated in the review for helping to make Swift a better language.
Freddy Kellison-Linn
Review Manager