Make cancelOnGracefulShutdown operations nonescaping #174
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,
cancelOnGracefulShutdown
looks to abide by this requirement, despite the compiler being unable to "see" this in the content. Indeed, it appears like thisoperation
arg 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
operation
never escapes.