Swift pitch: send and @oneway for fire-and-forget actor calls

Swift is considering a native fire-and-forget path for actor method calls. A second-round pitch from Konrad Malawski introduces a send expression and an @oneway marker so callers can hop onto an actor without awaiting a result, without paying for a full unstructured Task, and with deterministic enqueue ordering.

The work started as distributed-actor remote-call semantics. Design exploration showed the same pattern is common for ordinary local actors: survey data cited in the pitch found roughly 70 percent of sampled call sites already used Task initializers purely to invoke actor methods from callbacks or other synchronous code. Structured concurrency remains the recommended default; send is framed as an explicit, narrower escape when breaking out of it, including cases where open-ended tasks make ordering or performance harder to control.

send would be limited to void-returning and discardable-result methods in the current draft. @oneway does not add a new function color. It signals intent, can appear in function types, and matters most for distributed actors, where the compiler must synthesize synchronous thunks and adopters want tight control over which APIs are one-way. Malawski has said he is open to dropping overloadability on @oneway so the attribute stays informative rather than part of mangling.

Early forum feedback pressed on naming (overlap with Sendable and with cryptographic “one-way functions”), whether discarding non-void results at the call site should be allowed, back-deployment to older OS libraries, and whether local send should be restricted to synchronous isolated methods. The author argues send must stay usable from synchronous contexts, that Task-based fire-and-forget will exist regardless, and that prior RPC systems already use oneway for the same idea. Legitimate patterns such as ordered “last element, then completion” sends are awkward today without a well-defined primitive.