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

John_McCall · 2024-03-25T22:40:33.478Z

borrowing transferring as proposed in the current proposal is almost useless —borrowing only changes parameter ownership, and ownership of the region is still transferred to the callee. As a result, the caller can no longer use the value other than having the responsibility to destroy it. The only reason to have this combination is if you need to adopt transferring to express a function's region-transfer semantics without breaking binary compatibility.

borrowing disconnected as I described above, where the borrowing also changes ownership of the region, is much more generally useful. Consider a function that does a "deep copy" of a non-Sendable value; such a function should probably express that the return value is disconnected from the argument. func deepCopy(value: T) -> T doesn't do that; the return value will be in the same region as the argument. Both func deepCopy(value: T) -> disconnected T and func deepCopy(value: borrowing disconnected T) -> T express the same thing: there's a default region that all the return values and parameters are in, and the annotation separates a specific return value / parameter (respectively) from that region, and since there are only two return values and parameters in the first place, you end up with the same effective "region ownership signature". But there's a big difference when you have other parameters or when the function is isolated. For example, a fully-general deepCopy on a graph would need some sort of context that maps old objects to their copies. The return value of that deepCopy is definitely not disconnected from that context, and I would say that calling the old object borrowing disconnected is more appropriate.^[1]

This is a little bit tricky because the context would need to hold references to the old objects as keys in its dictionary. However, since it doesn't mutate those objects or build new references to them in the new objects, it does preserve the separateness of their region. It would be safe to use ObjectIdentifier or a similar trick in the implementation of the context. ↩︎

MPLewis · 2024-03-25T23:05:50.695Z

Just to throw another keyword option into the mix, how about reisolating? It sticks with the "isolate" base used in SE-0313/0420 and I think adequately describes that the parameter/return value is being moved from one isolation to another.

hborla · 2024-03-26T01:20:44.451Z

gregtitus:

In the transferringParameterConversions() and transferringResultConversions() examples there is no type change happening in the first line of either of these. If that's intentional, what's it demonstrating?

Nothing interesting! I wanted to demonstrate a successful conversion, but you're right that this isn't a conversion at all.

gregtitus:

My understanding of "the disconnected region is transferred away" means the whole region is now invalid, so this would also error? What would the error message look like?

Yes, that's correct. The compiler will diagnose the point of concurrency where the disconnected region is transferred away (i.e. at the await acceptTransfer(...), then note the potential for concurrent access at print(ns2). @Michael_Gottesman is also working on diagnostics for region history so the compiler can show a note at the point where ns2 and ns1 are assumed to reference each other at the initialization of ns2.

gwendal.roue:

Now that this proposal updates resume(returning:) so that it transfers the value, I have a third way to write makeValue:
// 3. No Sendable constraint, transferring output
public func makeValue<T>(
  _ value: @escaping @Sendable () -> transferring T
) async -> transferring T
What do you think?

I think this is a good question, and it's worth a section in the proposal about how to choose between Sendable and transferring in API design. In general, Sendable is a subset of transferring because a value with Sendable type is always safe to transfer. The times when you should prefer Sendable over transferring is if you truly need to share the value across multiple isolation domains at once. For example, if you were writing a concurrent map API, you'd want the closure parameter to be @Sendable instead of transferring because you'd want to invoke the closure in multiple child tasks concurrently, which isn't possible with a transferring closure parameter.

gwendal.roue:

Should I prefer this third solution?

I think in your case, using a transferring result instead of requiring that the result type be Sendable will make your API usable with more inputs.

gwendal.roue:

Would it "lock" my implementation to continuations (with difficulties making it evolve in the future, at constant api)?

I don't quite understand this question. How exactly are continuations involved here? I know you were comparing your API to the resume(returning:) API, but I'm not sure what you mean by "locking" your implementation to continuations.

gwendal.roue:

Could it create difficulties for callers (can it be less ergonomic to require a closure with a transferring output that just constraining T to be Sendable)?

Because a type conforming to Sendable satisfies the requirements of transferring, I can't think of a way the API would be less ergonomic by using transferring instead of Sendable.

gwendal.roue · 2024-03-26T06:58:32.101Z

hborla:

Sendable is a subset of transferring because a value with Sendable type is always safe to transfer.

That is a great sentence

I still have doubts, and I'll try to rewrite my initial questions, hoping they are more clear. In the sample codes below, I'll use logger.print as a placeholder for "stuff that the developer wants to do when debugging/benchmarking/tracing" and ideally would not come in the way.

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
}

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

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

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

public func makeValue<T>(
  _ value: @escaping @Sendable (Context) -> transferring T
) async -> transferring T
{
    let context = await getContext()
    let v = value(context)
    await logger.print(v)
    return v
}

Dmitriy_Ignatyev · 2024-03-26T09:37:00.438Z

Should we have to try this chance with a separate pitch? Swift 6 seems to be a great point for such renaming after Concurrency incubation period. For me this is similar to the case when AnyObject was introduced as a better option with deprecation of class.

Dmitriy_Ignatyev · 2024-03-26T09:44:39.821Z

Torust:

Could something like ownregion work? I think adjectival forms (ownregion, noregion, disconnected) make more sense than verbal forms

I like the idea very much, +1. One more variant - detachedRegion.
Something with region word is rather specific and unique to not overlap with domain and current language terms.

MPLewis:

Just to throw another keyword option into the mix, how about reisolating?

also +1

orobio · 2024-03-26T15:35:39.611Z

I think sending makes perfect sense. It’s sending a value, which means that the value must be sendable. Either because it conforms to Sendable, or because it’s disconnected.

hborla · 2024-03-26T15:53:18.182Z

Dmitriy_Ignatyev:

Should we have to try this chance with a separate pitch?

I personally do not think there is any value in trying to rename Sendable. The name of Sendable is fine, and no matter what name it has, there will be a learning curve that folks go through to internalize the term of art and what it means semantically in Swift's concurrency model. Many people have already internalized what a conformance to Sendable means, and I think changing the name of it now is actively harmful to those who have already put in the effort to internalize Sendable. The only thing that's changing now is the ability to pass non-Sendable values over isolation boundaries when there's no potential for concurrent access, and we can bikeshed how to explain the difference between a "sendable value" versus a "sendable type".

orobio:

I think sending makes perfect sense. It’s sending a value, which means that the value must be sendable. Either because it conforms to Sendable, or because it’s disconnected.

I think that the value versus type distinction is one that people have been confused by in the past (e.g. type-level abstraction versus value-level abstraction), and the learning curve may be easier if we use a different term for sendable values whose type does not conform to Sendable. On the other hand, we use somewhat different terms and very different syntax for global-actor isolation and actor-instance isolation, and people are still confused by the difference between the type-dependence versus value-dependence in actor isolation.

hborla · 2024-03-26T16:35:26.348Z

I still think sending is not the right term because what's needed is a stricter condition than a "sendable value". If this call crosses an isolation boundary, all argument values have to be "sendable", either because they're disconnected or the type is Sendable. But with transferring as proposed here, the condition is that the value has to be in a separate region from all other argument values so the callee can merge that value into a region that's different in some way from the other argument values.

orobio · 2024-03-26T17:08:01.161Z

hborla:

But with transferring as proposed here, the condition is that the value has to be in a separate region from all other argument values so the callee can merge that value into a region that's different in some way from the other argument values.

That’s a good point. If we want these semantics, I’d say we need something that communicates this properly, i.e. disconnected.

jeremyabannister · 2024-03-26T18:36:43.138Z

Jumhyn:

It's not the case, for instance, that a sendable T may be passed to a function requiring a U: Sendable, so it's not the case that sendable T is Sendable; huh?

To me this seems to be the biggest problem with choosing sendable T. I think the confusion could be attributed to the fact that it looks like the value is of a new type that is related to T, but which has been made sendable, but that’s not quite right, at least according to how types have always worked up until now, because the simple fact of passing the value to another transferring function suddenly “changes its type”, in the sense that the transferability has been removed and now it’s just a normal value of type T. The sendable in this case denotes a statically assessed attribute of the value, but rather than the attribute being fixed for the lifetime or the value (like its type is) it can change under a variety of conditions.

Maybe we can change the syntax to somehow reflect this a bit better. At the moment, however, no obviously clearer syntax occurs to me.

Jumhyn · 2024-03-26T19:29:46.424Z

hborla:

If this call crosses an isolation boundary, all argument values have to be "sendable", either because they're disconnected or the type is Sendable. But with transferring as proposed here, the condition is that the value has to be in a separate region from all other argument values so the callee can merge that value into a region that's different in some way from the other argument values.

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?

hborla · 2024-03-27T03:03:23.523Z

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:

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
  }
}

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 · 2024-03-27T03:23:06.859Z

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 · 2024-03-27T09:08:26.044Z

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 · 2024-03-27T09:19:25.211Z

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

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

hborla · 2024-03-28T15:24:09.675Z

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 · 2024-03-28T16:27:57.044Z

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 · 2024-04-16T23:00:45.892Z

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.

John_McCall · 2024-04-16T23:23:00.125Z