Add async overloads of all OutputSpan providing APIs
#545
Conversation
## Motivation It is currently not possible to use the new `OutputSpan` based APIs in asynchronous contexts. In particular, it is not possible to initialize or append to a `Unique/RigidArray` by reading asynchronously from the network or a file. ## Modifications This PR adds new overloads to all the existing APIs that provide an `OutputSpan` to take an asynchronous closure. The PR also adds tests for all those new methods to show that they are properly working. ## Result We can now interact with these output spans asynchronously.
| ) async throws(E) { | ||
| self.init(capacity: capacity) | ||
| try await edit(body) | ||
| } |
There was a problem hiding this comment.
This might be acceptable to add those overloads to swift-collections but I think this doesn't really scale well. Any API that needs to wrap this needs to do the same dance.
Is there a better way to describe this pattern, maybe with some kind of builder pattern that can be used as an intermediate step that needs to finalized?
There was a problem hiding this comment.
I agree this isn't scalable. This PR is mostly for demonstrating that we need these OutputSpans to be accessible in async contexts. The pitch contains an alternative considered section for this but it argues that the closure based approach taken here is better than wrapping each OutputSpan into a new type or making OutputSpan have a closure-clean-up.
2 participants
Motivation
It is currently not possible to use the new
OutputSpanbased APIs in asynchronous contexts. In particular, it is not possible to initialize or append to aUnique/RigidArrayby reading asynchronously from the network or a file.Modifications
This PR adds new overloads to all the existing APIs that provide an
OutputSpanto take an asynchronous closure. The PR also adds tests for all those new methods to show that they are properly working.Result
We can now interact with these output spans asynchronously.