Let me clarify my point from the other thread. We should definitely have some way to determine the formal isolation of the async let initializer that's better than always treating it as non-isolated. Doing that will require a language proposal; we can't just fix it in the implementation, we have to actually come up with a rule. That proposal won't depend on @isolated(any) in any way: while it's totally reasonable to think of async let as putting the expression in an implicit closure that's passed to a specialized task-creation function, which ought to take an @isolated(any) function like all the other ones do — and it is indeed implemented that way — none of that is actually exposed in the language. As a result, the actual proposal would just be "the initializer is now potentially isolated, and here's the rule for determining that".
That doesn't mean it wouldn't have any proposal dependencies. I personally think the right rule is something like "if the initializer is a call expression, then the initializer is isolated the same way as the callee of that call."[1] That rule stands alone, but it would be better if it built on top of the closure-isolation proposal, since explicit closure isolation would provide an explicit way to specify the isolation of an async let initializer in cases where the implicit rule wasn't good enough, e.g.:
async let x = { [isolated myActor] in ... }()
Of course, the way I've written the @isolated(any) proposal also builds on top of the closure isolation proposal in the same way: isolated closures gives you a consistent way to write things that otherwise can only happen in special cases.
This rule doesn't quite work — in general, we need the isolation to be knowable without running any code in advance, which means that an initializer like
returnAnActor().isolatedMethod()must be non-isolated. It would also be defeated by something like a type coercion or a cast on the call result, which seems very questionable. But still, something in that general area seems like the most natural thing to do. ↩︎