Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
in my recent testing, it seems
nonisolated(nonsending)does not grant the ability to actually procure a reference to theisolatedparameter in a way that allows isolating closures in the same manner that capturing an explicitisolatedparameter does. i suppose in this case it doesn't matter since the parameter isn't being captured by the body closures, but that does make me wonder if those closures are actually not being isolated in the intended manner currently.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you briefly expand what closures you are worried are not isolated in particular?
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
so, the concern would be that even though the method inherits isolation by default (in the original formulation), the isolated parameter is unused within the body closures. this is true in the prior version with an isolated parameter, and seems to also be true even after converting to implicit caller isolation inheritance. this means the actual 'work' invoked by the
with*runtime methods isn't isolated, so IIUC it's going to require an executor hop if the caller is actor-isolated. this can be seen in this sort of example: https://swift.godbolt.org/z/GP4dPhfKv.Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah so you are talking about the
withTaskCancellationHandlerandwithCheckedContinuationhandler. Both of them have open PRs to address these issues swiftlang/swift#85191 & swiftlang/swift#85518Edit: I see that you left a comment on the latter PR. The hop should be eliminated and I think @gottesmm is looking into that.