I've noticed quite a lot of confusion between @isolated(any) and @_inheritActorContext. Because they are used together by Task, but the underscored attribute is not visible in documentation, many people reach the conclusion that the isolation inheritance actually comes from @isolated(any).
And lately, this has got me thinking. I'm having a hard time coming up with real problems that are only solvable by one but not the other. Are there any?
This is particularly relevant for Closure isolation control, because that proposal would make isolation inheritance public and easier tool to use. It seems like the only motivation for this is a path to change the sematics around capturing isolation.
This is a round-about way of me contemplating fusing these two concepts into one. I like the idea of simplying the language in this way, but I'm having trouble figuring out if this is safe and/or reasonable thing to do.
I agree that these two attributes are easy to confuse, especially with @_inheritActorContext not having been formalized / hidden from documentation / etc, but @_inheritActorContext and @isolated(any) have different effects.
@isolated(any) allows you to recover the isolation of a function value as an (any Actor)? value. It has no impact on the inferred isolation of a closure whose type includes @isolated(any), and that's where I think people get confused. If you take @isolated(any) away, isolation inference behaves exactly the same way. For non-@Sendable/sending closures, isolation is already effectively "inherited" from the enclosing context where the closure is formed.
@_inheritActorContext is only useful when you have a closure that either @Sendable or passed to a sending parameter, and it applies the same isolation inference behavior that you would get if that closure didn't have those other concurrency annotations.
I think the need for @isolated(any) is fairly rare; the task creation APIs use the isolation value to enqueue the operation directly on the isolated actor to resolve the issue that tasks always (used to) begin on the generic executor. That problem wasn't caused by closures having the wrong static isolation, it was because the implementation of the task creation APIs didn't have the actor value to enqueue on.
I think @isolated(any) is generally the right tool for when you accept a function from the user that you're happy to invoke with any arbitrary isolation. If you have a subscription API which takes a callback, for example, and you don't specifically need to deliver events in some specific way for synchronization/ordering purposes, you should probably take the callback as an @isolated(any) function so that users can provide a function with whatever isolation they like.
I think we should also offer a similar feature with protocols, although that would take more effort to design.
Thanks @hborla and @John_McCall for the clarifications. But I find myself still slightly hung up here.
Task uses both these annotations, and I get it. The task group family addTask method uses only @isolated(any), but does not inherit isolation. I sometimes think of task groups as conceptually similar to:
for _ in count {
Task {
}
}
But, groups have totally different semantics because they do not inherit the enclosing scope's isolation like Task does. This actually makes them quite hard to use in some circumstances compared to a collection of Task values.
I'm not (currently anyways ) arguing for a change these APIs. But I'm really having hard time understanding why these two concepts a) must be separate and b) should also be so easy for developers to use separately.
Given that @isolated(any) allows the creator of the closure to specify any isolation, it kinda feels like fusing that with @_inheritActorContext would just give it an unsurprising default, one that could still be changed if needed just like you can with Task.
Aside from the obvious impact on task groups, are there any other concrete negative implications I'm not thinking of?
It sounds like you’re really arguing that more closures should maintain the isolation of the surrounding context — that that should be more like a default behavior of closures, overridden only by specific contextual requirements that the closure should use a different isolation.
I think I'm arguing that it's weird to have just @_inheritActorContext or @isolated(any) but not both? I'm definitely not suggesting that closures should change in the general case.
Well, I mean, you've already identified a case, task groups, where we want to take an @isolated(any) function but explicitly don't want @_inheritActorContext because we don't want the tasks to all potentially get serialized just because you're starting them from a serial domain.
) arguing for a change these APIs. But I'm really having hard time understanding why these two concepts a) must be separate and b) should also be so easy for developers to use separately.