Make cancelOnGracefulShutdown operations nonescaping #174
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
FranzBusch
reviewed
Feb 16, 2024
| } | ||
| } | ||
| public func cancelOnGracefulShutdown<T:Sendable>(_ operation: @Sendable () async throws -> T) async rethrows -> T? { | ||
| return try await withoutActuallyEscaping(operation, do: { operationEscaping in |
There was a problem hiding this comment.
This is currently not safe to do see: https://forums.swift.org/t/pitch-non-escapable-types-and-lifetime-dependency/69865/23
Once TaskGroup becomes ~Escapable we can make this change here.
There was a problem hiding this comment.
Thanks for the info. Hadn't seen this - will definitely follow this development and discussion.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Hello.
As of release
v2.4.0, please consider the following function from the public API.I was working on a new project today and while architecting the shutdown procedures, I found myself wanting to use this function a lot. Very useful!
Unfortunately, I'm the kind of programmer that gets hopelessly lost in the details and semantics, and this is one of those scenarios where a perfectly valid implementation sits with me as "sub-optimal". Why? Well, I don't really see why this needs to take an escaping operation. In my personal utopian world, this function would work exactly as it is implemented today, simply with a non-escaping operation arg.
As we know, the primary factor that distinguishes an escaping block and non-escaping block is when the function will be executed. In order to be considered non-escaping, the operation must execute within the lifecycle of the function. To my best interpretation,
cancelOnGracefulShutdownlooks to abide by this requirement, despite the compiler being unable to "see" this in the content. Indeed, it appears like thisoperationarg always executes within the boundaries of the root function.As such, I have implemented this proposal to force the nonescaping semantics on this function. I'm no expert of compilers by any stretch of the imagination, but I suspect the compiler will be able to work much more efficiently with memory with the correct knowledge that the
operationnever escapes.