[AsyncStreaming] Add bidirectional adapters for the async writers#424
Merged
Conversation
## Motivation Real transports deliver structured data alongside end-of-stream and need to fuse the last write with the close. HTTP trailers and gRPC status are the obvious cases. Neither can be expressed by an empty-buffer terminator, and both lose H2/H3/QUIC's DATA+END_STREAM coalescing without a fused call. ## Modification Adds `FinalElement: ~Copyable = Void` as a primary associated type on all four protocols. `AsyncReader` delivers it via a `consuming FinalElement?` closure parameter; `CallerAsyncReader` returns it. Both writers gain a consuming `finish` carrying the last chunk and the payload in one call. `forEachBuffer`, `collect`, and the `pipe` variants thread the payload through. `collect` becomes consuming and gains a `Void`-final overload returning just the result. Adds an "Alternatives considered" entry covering what would break without this: HTTP body, gRPC, and fused close on H2/H3/QUIC. ## Result The four protocols can back HTTP body, gRPC streaming, and similar shapes without giving up the fused close. Default `Void` keeps simple conformers unchanged; `Never` marks infinite streams. Custom and `~Copyable` payloads work end to end.
## Motivation It is quite common to have one type of writer and wanting to adapt to the other type of writer. ## Modifications This PR adds two adapters into either direction between the writers to make conversion seamless. ## Result It is easy to go from one type of writer to the other type.
FranzBusch
force-pushed
the
fb-writer-adapters
branch
from
b149503 to
97019b3
Compare
Catfish-Man
approved these changes
Jun 2, 2026
Catfish-Man
left a comment
Catfish-Man
left a comment
Member
There was a problem hiding this comment.
Looks good :) nice functionality
| /// closure-supplied buffer. The underlying writer's deferred-flush | ||
| /// behavior, if any, is preserved. | ||
| @available(macOS 15.0, iOS 18.0, tvOS 18.0, watchOS 11.0, visionOS 2.0, *) | ||
| public struct AsyncWriterCallerAsyncWriterAdapter< |
Member
There was a problem hiding this comment.
[standard comment about names goes here]
we'll figure it out later
| innerBuffer.append(element) | ||
| } | ||
| while innerBuffer.freeCapacity > 0 { | ||
| guard let element = consumer.next() else { return } |
Member
There was a problem hiding this comment.
Getting all of this to lower to memcpy calls when the types are appropriate is going to be a fascinating exercise at some point. I never quite got it to for AsyncBytes
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Motivation
It is quite common to have one type of writer and wanting to adapt to the other type of writer.
Modifications
This PR adds two adapters into either direction between the writers to make conversion seamless.
Result
It is easy to go from one type of writer to the other type.