[Pitch] Improve diagnostic when attempting to send "task-isolated" value

Evolution Pitches
, , , ,
1

It can be very surprising when code which was previously compiling is suddenly failing with an error like:

Task-isolated 'foo' is passed as a 'sending' parameter; Uses in callee may race with later task-isolated uses

or:

Sending value of non-Sendable type 'Foo' risks causing data races

Passing task-isolated value of non-Sendable type 'Foo' as a 'sending' parameter to initializer 'init(_:)' risks causing races inbetween task-isolated uses and uses reachable from 'init(_:)'

My understanding of Region Based Isolated (RBI) is that the compiler silently colors each value as either bound to the current "isolation region" or not, and if you attempt to send a "bound" value ("task-isolated"?) to a different region then you will get an error similar to those above.

What I had not thought about until being bitten by this issue again just now is the full set of rules that determine whether a value is "task-isolated" or "disconnected", and the big rule that I wasn't conscious of is that when a value is initialized it will be disconnected if all values passed to the initializer are disconnected, but if one of those arguments becomes task-isolated then the value being initialized is also considered task-isolated.

I think that both for the seasoned concurrency expert who wants to fix the given isolation issue and for the novice who is trying to build their mental model about Swift Concurrency it would go a long way if at the site of the attempt to send the task-isolated value one of the diagnostics listed the task-isolated initializer arguments that are responsible for infecting the value and binding it to the current region.

I'm sure that there are all kinds of edge cases where such a list could not be generated, but it seems like it should be pretty straightforward in the simpler cases, and given how opaque the RBI errors are and how much effort the Swift team is putting toward branding Swift Concurrency as reasonably approachable this seems to me like it should be a somewhat high priority.

2 Likes
2

@hborla @John_McCall, do you think an improvement along these lines is viable?

3

There's always a danger when suggesting information like this that it might end up misleading programmers, but yeah, it's reasonable to try to provide it.

1 Like
4

The rules are explained in SE-0414 "Rules for Merging Isolation Regions" and "Transferring Values and Isolation Regions" sections.

Take this code as an example:

class NonSendable1 {}
class NonSendable2 {}
class NonSendable3 {
    let ns1: NonSendable1
    let ns2: NonSendable2

    init(ns1: NonSendable1, ns2: NonSendable2) {
        self.ns1 = ns1
        self.ns2 = ns2
    }
}

func test() {
    let ns1 = NonSendable1()
    let ns2 = NonSendable2()
    let ns3 = NonSendable3(ns1: ns1, ns2: ns2) // Merging regions
    Task {
        print(ns1) // Transfering the merged region
    }
}

When NonSendable3.init(ns1:,ns2:) is called, regions are merged:

Given a function $f$ with arguments $a_{i}$ and result that is assigned to
variable $y$:

$$
y = f(a_{0}, ..., a_{n})
$$

  1. All regions of non-Sendable arguments $a_{i}$ are merged into one larger
    region after $f$ executes.
  2. If any of $a_{i}$ are non-Sendable and $y$ is non-Sendable, then $y$ is in
    the same merged region as $a_{i}$. If all of the $a_{i}$ are Sendable,
    then $y$ is within a new disconnected region that consists only of $y$.
  3. ...

Closure is in the same region as the variables it captures. When it's passed to Task.init, the merged region is transferred:

Formally, when we pass a non-Sendable value $v$ into a function $f$ and the
call to $f$ crosses an isolation boundary, then we say that $v$ and $v$'s
region are transferred into $f$.