[Pitch #2] SE-0371 Isolated & async deinit

Nickolas_Pohilets · May 5, 2023, 2:29pm

Hello,

I've updated previous proposal for isolated synchronous deinit, and would like to pitch it again.

The main updates are:

Isolation for synchronous deinit now is an opt-in using the isolated keyword.
Copying task-locals can be disabled for performance using new @resetTaskLocals attribute, but by default task-locals are copied.
Support for asynchronous deinit was added. Asynchronous deinit always executes concurrently with the code that triggered last release.

nickolas-pohilets/swift-evolution/blob/mpokhylets/isolated-deinit/proposals/0371-isolated-synchronous-deinit.md

# Isolated synchronous deinit and asynchronous deinit

* Proposal: [SE-0371](0371-isolated-synchronous-deinit.md)
* Author: [Mykola Pokhylets](https://github.com/nickolas-pohilets)
* Review Manager: [Frederick Kellison-Linn](https://github.com/jumhyn)
* Status: **Returned for revision**
* Implementation: [apple/swift#60057](https://github.com/apple/swift/pull/60057)
* Review: ([pitch](https://forums.swift.org/t/isolated-synchronous-deinit/58177)) ([review](https://forums.swift.org/t/se-0371-isolated-synchronous-deinit/59754)) ([returned for revision](https://forums.swift.org/t/returned-for-revision-se-0371-isolated-synchronous-deinit/60060))

## Introduction

This feature allows `deinit`'s of actors and global-actor isolated types (GAITs) to access non-sendable isolated state, lifting restrictions imposed by [SE-0327](https://github.com/apple/swift-evolution/blob/main/proposals/0327-actor-initializers.md). This is achieved by providing runtime support for hopping onto executors in `__deallocating_deinit()`'s.

## Motivation

The combination of automatic reference counting and deterministic deinitialization makes `deinit` in Swift a powerful tool for resource management. It greatly reduces need for `close()`-like methods (`unsubscribe()`, `cancel()`, `shutdown()`, etc.) in the public API. Such methods not only clutter the public API, but also introduce a state where object is already unusable but is still able to be referenced.

Restrictions imposed by [SE-0327](https://github.com/apple/swift-evolution/blob/main/proposals/0327-actor-initializers.md) reduce the usefulness of explicit `deinit`s in actors and GAITs. Workarounds for these limitations may involve creation of `close()`-like methods, or even manual reference counting if the API should be able to serve several clients.

In cases when `deinit` belongs to a subclass of `UIView` or `UIViewController` which are known to call `dealloc` on the main thread, developers may be tempted to silence the diagnostic by adopting `@unchecked Sendable` in types that are not actually  sendable. This undermines concurrency checking by the compiler, and may lead to data races when using incorrectly marked types in other places.

This file has been truncated. show original

Please share any thoughts, questions or suggestions!

Links:

Pitch #1 - Isolated synchronous deinit
Proposal Review #1 - SE-0371: Isolated synchronous deinit
Generic discussion about second iteration - Isolated synchronous deinit #2
Discussion about performance of async deinit - Async deinit: Optimization Goals
(Absence of) discussion about semantics of async deinit - Async deinit: Semantics

mickeyl · May 6, 2023, 6:00am

Thanks. I’m missing this in some cases, so very welcome from me.

Fritzt · May 7, 2023, 3:36pm

+1, especially for the 'isolated deinit'. For me it's closing a gap for classes derived from UIView or UIViewController as outlined in the proposal.

tourultimate · May 8, 2023, 4:35pm

Do I understand the proposal correctly that synchronous deinit defaults to non-isolated, but asynchronous deinit defaults to isolated?

Nickolas_Pohilets · May 8, 2023, 5:39pm

Yes.

Of course, if async deinit is inside a class without isolation, then it also will be nonisolated.

As mentioned in the proposal the main reason is to discourage people from awaiting on individual properties.