Testing @Sendable closures

[rcarver]

Hoping to clarify the correct way to test fireAndForget effects with @Sendable endpoints. Given a client that looks like this:

struct EditorClient: Sendable {
    public var continuousEditing: @Sendable (Bool) async -> Void
}

Reading the docs for ActorIsolated seems to indicate that this is the correct approach:

let isContinuousEditing = ActorIsolated<Bool>(false)
store.dependencies.vesperControlsClient.continuousEditing = { await isContinuousEditing.setValue($0) }
// exercise the store...
await isContinuousEditing.withValue { XCTAssertTrue($0) }

But simply marking the closure as @MainActor also seems to work:

var isContinuousEditing = false
store.dependencies.vesperControlsClient.continuousEditing = { @MainActor in isContinuousEditing = $0 }
// exercise the store...
XCTAssertTrue(isContinuousEditing)

Is there a meaningful difference between these two? I'm guessing the ActorIsolated approach would work any any situation, but since tests must be marked @MainActor then the second approach is sufficient?

---

Side note: I have another identical-looking endpoint requires marking the closure as @Sendable. Any idea why? (Xcode Version 14.0 (14A309))

public struct VesperRenderClient: Sendable {
    public var render: @Sendable (RenderRequest) async -> Void
}
public struct RenderRequest: Equatable, Sendable { }

let renderRequestCount = ActorIsolated<Int>(0)
//  Removing @Sendable annotation gives warning:
// ⚠️ Converting non-sendable function value to '@Sendable (RenderRequest) async -> Void' may introduce data races
store.dependencies.vesperRenderClient.render = { @Sendable _ in 
  await renderRequestCount.withValue { $0 += 1 }
}

[mbrandonw]

Hi @rcarver, I think using @MainActor and dropping the ActorIsolated should be ok and maybe something we should even do more of in our case study tests. In the future when we finish disentangling TCA from Combine we can hopefully run the Store on a non-main global actor, and then in that case ActorIsolated might be more handy.

And as for the second question... I'm not sure. Seems like the closure you provide is @Sendable so don't know why it's complaining.

[mbrandonw]

I was able to get rid of most ActorIsolated usages by using this trick, so that's nice. It worked for all tests, but there are spots where ActorIsolated is used to define preview and live implementations of dependency clients, and I don't believe those can be refactored because you "can't" mark liveValue, etc. as @MainActor.

Now, I quoted "can't" because it seems you shouldn't be allowed to do that since isolated things shouldn't be allowed to satisfy non-isolated requirements, but apparently under certain incantations you can do that:

struct A {}
extension A: DependencyKey {
//  @MainActor static var liveValue: Int { 42 } // ⚠️
//  @MainActor static var liveValue = 42 // ⚠️
  @MainActor static let liveValue = 42 // ✅
}

All 3 of these should be warnings, in my opinion, but only the first two actually warn. I think this has got to be a bug in Swift and should probably file it.

[mbrandonw]

Filed a bug: swiftlang/swift#61300

[rcarver]

Nice one @mbrandonw! Yeah I saw ActorIsolated used for clients in isowords, and that totally makes sense. Handy tool, now we just need a similar one for streams.