Illegal capture in `withTaskGroup`?

Using Swift
21

Your examples with String seem irrelevant, since it's both Copyable and Sendable, which means it doesn't interact with sending at all. If you want to fairly compare reference and value types, you need to construct a non-Sendable value type, and have a clear way to control whether they're considered to be "in their own region" or not.

consuming is for the caller only — if the type is non-Copyable, whatever's passed into the argument is unavailable afterward in the caller (it affects refcounting behavior in both caller and callee for reference types, but mostly that doesn't matter).

sending is for both the caller and callee — in the caller you must prove the value is "in its own region", and in the callee you may assume the value is "in its own region" (which allows it to be safely transferred to another isolation).

There is only a slight relationship between those things — if a value is non-Copyable then it can't be used again in the caller whether it's sent to a sending parameter or a consuming parameter (not that a borrowing sending parameter makes any sense anyway).

Once-callability and sending don't intersect any more strongly either — just because a once-callable closure would be non-Copyable and have a consuming call operator, it could still be "in its own region" (and therefore eligible for sending) or not, depending on what it captures.

1 Like
22

I'm afraid I can't agree. I was aware of the difference you mentioned. I believe you meant the code like the following, in which str in test() and str in send(_:) are two different copies.

func send(_ str: sending String) {
    str = "xyz"
}

func test() {
    let str = "abc"
    send(str)
    print(str) // "abc"
}

However, test2() in #87076 is different. The closure of capture() captures a str in test function by reference. A closure capturing a mutable value is non-Sendable. It's sending only when the mutable value it captures is transferred together with it. That's why str in test function should be sending too. I'm pretty sure you know all of these.

func capture(_ fn: sending () -> Void) {
  fn()
}

func test2() {
  var str = "abc"
  capture { str = "xyz" }
  print(str) // OK: output "xyz"
}

The following prove that capture() changes str in test function:

  • if you change str in test function to a let variable, the code doens't compile.
  • note that print(str) shows that, after calling capture(), str in test function has been changed.

The same aplies to test4(). The two capture() calls change str in the test function.

func test4() {
  var str = "abc"
  capture { str = "xyz" }
  capture { str = "123" }   // OK
  print(str) // "123"
}

That makes sense. I wouldn't think of it myself. Thanks!

EDIT: I should add your interpretation of sending isn't exactly how it works currently. For example, if you transferred str to another isolation in closures of test2 and test4, there would be data race. This is currently impossible because compiler doesn't allow re-send a sending value in closure (#85231).

23

I think you've been tripped up by the sendability of String again though — you're conflating the rules around the capture with the rules around exclusivity of access to the local variable.

If str was any non-Sendable type, including a non-Sendable value type, then the closure can't be passed to the sending parameter.

The local variable of the calling function though, can safely be mutated by the non-escaping closure. If you add @escaping to capture's argument, this won't compile even with a capture of a Sendable type.

2 Likes
24

You explanation about law of exclusivity and non-escaping closure would make sense to me if capture()'s closure parameter didn't have sending modifier. IMO sending modifier should have some impact even if it's used with a non-escaping closure. It seems weird to me that its behavior depends on whether the captured value is of reference type or value type.

I suppose you meant test1 and test3 in my report, right? That is exactly why I filed #87076. I can't see how sendability of String can explain the difference. Or let me put it in another way, are there data race in test1 and test3 in my report? No, I don't think so. IMO they don't compile only because the semantic of sending modifier and I think the same should apply if the captured value is a mutable string.

EDIT: if you remove print() statement in test1 and test3, they compile. That's by design. A closure capturing a non-Sendable instance can be passed to sending parameter if that instance is transferred together with it.

25

Correct. If you mark fn as @Sendable, you will get an error diagnostic as well, since str is captured by reference.

struct NotSendable {}

@available(*, unavailable)
extension NotSendable: Sendable {}


func capture(_ fn: sending () -> Void) {
  fn()
}


func test() {
  var ns = NotSendable()

  capture { ns = NotSendable() } // sending value ... risks causing data races
  
  print(ns)
}





func capture2(_ fn: @Sendable () -> Void) {
  fn()
}

struct SendableStruct: Sendable {}


func test() {
    var ss = SendableStruct()

    capture2 { print(ss) } // reference to captured var 'ss' in concurrently-executing code

    print(ss)
}


func test2() {
    var ss = SendableStruct()

    capture2 { [ss] in print(ss) } // Okay

    print(ss)
}