[Amendment] SE-0466 Control default actor isolation inference

Evolution Proposal Reviews
5

Actually the amended file currently contains this snippet:

nonisolated protocol Q: Sendable { }

 // nonisolated
 struct S2: Q { }

 // @MainActor
 struct S3 { }

 extension S3: Q { }

This behavior would void the expected benefits of the amendment, and I suggest that this is reconsidered.

As the author of GRDB, I have users who frequently write (in the same file):

<<< Player.swift
import GRDB

struct Player: Codable, Identifiable { ... }

// MARK: - Database

extension Player: TableRecord { }

In those files, conformances are declared on an extension, not right on the type declaration. Some users even conditionally conform to GRDB protocols with #if canImport(GRDB), which, well, is one more reason for splitting the type declaration and the conformance extension.

We already have multiple precedents in the language where same-file extensions are handled as if the conformance was included right on the type definition. Please extend this handling to the topic of this amendment.

If Player were still MainActor-isolated in the above sample code, well, those users would be rightfully disappointed..

My second question Is about nested types. Do you confirm that all the Nested types below will be non-isolated?

The impact of GRDB is the following. The Columns enum MUST be non-isolated so that the snippet in the "Usage" section is able to access name from the nonisolated closure executed by the read method:

<<< Player.swift
import GRDB

struct Player: Codable, Identifiable {
  var id: Int64
  var name: String
}

// MARK: - Database

extension Player: FetchableRecord, // can decode database rows
                  TableRecord      // can generate SQL
{
  enum Columns {
    static let name = Column(CodingKeys.name)
  }
}

// <<< OtherFile.swift
// Usage
let player = try await dbQueue.read { db in
  // We're in a non-isolated closure here.
  try Player.filter { $0.name == "Arthur" }.fetchOne(db)
}
3 Likes