SE-0430: `transferring` isolation regions of parameter and result values

[hborla (Holly Borla)]

@Jumhyn

I'm not sure I totally grasp the distinction you're drawing here... is it that in the first case ("sendable values") you could hypothetically be passing some non-Sendable arguments which are all in a region together, which doesn't work with transferring as-proposed?

SE-0414 does let you pass "sendable values" with non-Sendable type over an isolation boundary. If the callee's isolation domain is actor isolated, region analysis has to assume that those values were merged into the actor's region, but if the callee is just isolated to the current task (i.e. it's a nonisolated async function), then you can still access all of the argument values when the call returns:

class NonSendable {}

func taskIsolated(ns: NonSendable) async { ... }

@MainActor func crossBoundary() async {
  let ns = NonSendable()
  await taskIsolated(ns: ns) 
  print(ns) // okay, ns can't have escaped into actor-isolated state
}

In the above code example, I consider ns to be a "sendable value" - it isn't referenced by any main actor isolated state, so it's safe to cross over the boundary at the call to taskIsolated, and because taskIsolated can't have merged the value into actor-isolated state, the caller has access to ns again after the call.

There are two use cases for transferring as proposed here:

1. A synchronous call that itself doesn't cross an isolation boundary wants to pass an argument value over an isolation boundary or stash it away into actor-isolated state in the callee. For example:

class NonSendable {}

@MainActor class MyClass {
  let ns: NonSendable
  nonisolated init(ns: transferring NonSendable) {
    self.ns = ns
  }
}

2. A call wants control over a specific argument value or the result value to indicate that it is not merged into the same region with the other arguments and results. For parameters, the callee can take advantage of the disconnected region by merging it into some other actor's region or transfer the value further. For results, the caller can take advantage of the result being in a disconnected region:

@MainActor func useOnMain(_ ns: NonSendable) { ... }

func transferAway(_ arg1: transferring NonSendable, arg2: NonSendable) async {
  await useOnMain(arg1) // okay
  await useOnMain(arg2) // error
}

For calls to transferAway above, it would be an error to pass two argument values that are already assumed to be in the same region.

[hborla (Holly Borla)]

@jrose

The "ABI compatibility" section of this proposal is where the notes on mangling should have gone. But if adding transferring can be done in a binary-compatible way (as long as the existing API is consuming), why does it change the mangling? Are we allowing people to overload on transferring vs not?

You can't overload on transferring as a direct parameter modifier, because overload resolution happens much earlier than region analysis, so calls to such a function would always be ambiguous:

class NonSendable {}

func overload(_: transferring NonSendable) { ... }
func overload(_: NonSendable) { ... }

overload(NonSendable()) // ambiguous

You can overload on parameter or result types that include transferring function types, though, e.g.

struct GenericType<T> {}
class NonSendable {}

func overload(_: GenericType<(NonSendable) -> Void>) { ... }
func overload(_: GenericType<(transferring NonSendable) -> Void>) { ... }

We can probably suppress transferring in the mangling when used directly on parameter and result types of function declarations, which would also allow adopting transferring in existing resilient APIs, like CheckedContinuation.resume(returning:), without resorting to silgen_name for ABI compatibility.

@jrose

I'd expect the error to be on the second use and the note on the first use.

We've deliberately inverted the SE-0414 diagnostics to emit the error at the point of concurrency and emit notes at the points of potential concurrent access (and eventually the points where two values are assumed to reference each other due to region merging). This isn't new with this proposal implementation, so if we want to continue discussing this, I suggest we do so in a separate thread.

[Dmitriy_Ignatyev]

@hborla

overload(NonSendable()) // ambiguous

You can overload on parameter or result types that include transferring function types, though, e.g.

So if one wants to make an overload, is it possible as a workaround to rewrite this:

func overload(_: transferring NonSendable) { ... }
func overload(_: NonSendable) { ... }

overload(NonSendable()) // ambiguous

to this:

func overload(_ argGetter: () -> transferring NonSendable) { 
  let transferringInstance = argGetter()
  ...
}
func overload(_ argGetter: () -> NonSendable) { ... }

overload() { NonSendable() } // ok

?

[Dmitriy_Ignatyev]

Is it possible to return a tuple where parameters have different transferring?

func getNonSendable() -> (transferring NonSendable_a, NonSendable_b, transferring NonSendable_c) {
  ...
}

[hborla (Holly Borla)]

@gwendal.roue

First, from the point of view of the developer who provides a () -> transferring T closure. Would the compiler refuse to compile the code below?

makeValue {
    let v = NonSendable()
    logger.print(v)
    return v
}

It depends on the type of logger and the isolation of print. If the type of logger is Sendable and print is not isolated, then v remains in a disconnected region by itself, and it's okay to return v as the value for a transferring result type.

@gwendal.roue

Same question, for the async variant () async -> transferring T:

makeValue {
    let v = NonSendable()
    await logger.print(v)
    return v
}

Same here, if logger is Sendable and print is (implicitly or explicitly) nonisolated, the this code is valid. The same is true for your last example.

@Dmitriy_Ignatyev

So if one wants to make an overload, is it possible as a workaround to rewrite this:

func overload(_: transferring NonSendable) { ... }
func overload(_: NonSendable) { ... }

overload(NonSendable()) // ambiguous

to this:

func overload(_ argGetter: () -> transferring NonSendable) { 
  let transferringInstance = argGetter()
  ...
}
func overload(_ argGetter: () -> NonSendable) { ... }

overload() { NonSendable() } // ok

?

No, overload { NonSendable() } would still require region isolation to disambiguate between the two overloads you wrote. If you specified the type of the closure explicitly, then the call would not be ambiguous.

@Dmitriy_Ignatyev

Is it possible to return a tuple where parameters have different transferring?

func getNonSendable() -> (transferring NonSendable_a, NonSendable_b, transferring NonSendable_c) {
  ...
}

No, transferring is only valid in nested positions in function types. You cannot write transferring structurally in tuple elements like this.

[benrimmington]

@John_McCall

Yeah, I agree that carving out a second highly generic word as a concurrency term of art is pretty concerning. It would be better to either build on the existing term or use a less generic term.

I haven't seen this mentioned before as a naming conflict, but Apple platforms already have a Transferable protocol — used by drag and drop, copy and paste, etc.

[beccadax (Becca Royal-Gordon)]

Hi everyone,

The proposal has been returned for revision to select a keyword that more closely aligns with concurrency terminology. It is otherwise quite satisfactory, and the general design has been accepted in principle. See the announcement thread for more details.