Swift 6 Strict Concurrency: Unresolved Behavior of nonisolated(unsafe) in Actor Captures

Answer to the core question

@nonisolated(unsafe) provides no static guarantee that a captured reference is free of data races. It merely silences the compiler’s Sendable check for that specific reference, allowing it to be accessed from any concurrency domain without isolation. Safety must be ensured by the programmer through manual review or runtime tools.

The compiler cannot detect** whether an unsafe capture is actually race‑free; it only verifies the presence of the attribute. Detection of unsafe captures therefore relies on manual audit or external tools such as Thread Sanitizer.

Marking a type with @unchecked Sendable opts the type out of Sendable checking entirely. Downstream code treats the type as Sendable, propagating the unsafe assumption, while the type’s memory layout remains unchanged and only the Sendable witness table is omitted from the ABI.

Likely explanation vs. confirmed facts

Likely explanation (based on language design)

• The attribute is intended as an escape hatch for incremental migration; it deliberately trades compile‑time safety for flexibility.
• Because the compiler cannot reason about arbitrary mutable state, it assumes the programmer has performed a manual audit when the attribute is present.
• @unchecked Sendable mirrors the same opt‑out principle at the type level, removing the conformance witness but leaving the type’s layout intact.

Confirmed facts (from Swift 6 strict concurrency specification)

1. @nonisolated(unsafe) suppresses the Sendable diagnostic for the annotated expression; no further static analysis is performed.
2. The compiler does not examine whether the referenced object is actually free of concurrent mutations; therefore a data race can still occur at runtime.
3. When a type is marked @unchecked Sendable, the generated SIL omits the Sendable conformance witness table, but the type’s field layout and size are unchanged.

Steps to verify the behavior in your project

# 1. Build with Swift 6 toolchain and strict concurrency
swiftc -strict-concurrency=complete -target x86_64-apple-macosx14.0 YourFile.swift
# 2. Capture a non‑Sendable class in an actor closure without any attribute → expect error
# 3. Add @nonisolated(unsafe) to the capture → error disappears
# 4. Run the resulting binary under Thread Sanitizer to see if a race is reported
# 5. To inspect the ABI effect of @unchecked Sendable:
swiftc -emit-sil -target x86_64-apple-macosx14.0 YourFile.swift | grep -A2 -B2 'Sendable'

Missing diagnostic detail that could change the recommendation

Is the captured reference mutable or immutable? If the reference is immutable (or only read‑only after initialization), the risk of a data race is lower, and the unsafe attribute may be acceptable with less extensive manual review. If the reference is mutable, a thorough audit or runtime sanitizer is strongly advised.