Thanks for the great writeup @ktoso.
I am really glad to hear that we are removing async deinits from this proposal since they come with a lot of implications and in my opinion new potentially unpredictability when used for resource management.
I am really curious about this since it sounds similar to what async deinits needed. Is there really a difference between spawning a job and a task? Spawning a job means we have to enqueue the job running the deinit on the executor of the actor. Which means this job can run at arbitrary times and in fact might never run if its priority is too low and the system is busy doing other work. This plays into this statement from the motivation section of the proposal:
The combination of automatic reference counting and deterministic deinitialization makes
deinitin Swift a powerful tool for resource management.
I strongly disagree with this and IMO deinit is not a great tool for resource management. From experience in the server ecosystem and developing iOS applications before that relying on deinit based clean-up results in all kinds of unpredictability in a program. It is hard to tell which thread is going to win the race to release the last reference and run the deinit. This makes it impossible to tell at what point in time an instance has been deinited.
I am afraid that when we introduce the implicit spawning of a job to run a deinit we are making this even worse by adding additional queueing to clean up the resource making it even more unpredictable when it is cleaned up.
Since the introducing of structured concurrency, with methods have been my go-to pattern to solve this problem of resource management. Before structured concurrency this wasn't always possible when the resource needed to be used asynchronously but now I didn't come across a resource management problem that couldn't be solved with a with method.