Re: [whatwg/streams] Proposal: `ReadableStream.withSafeResolvers()` (Issue #1359)

juner left a comment (whatwg/streams#1359)

@saschanaz 

That’s a fair concern, and I agree that anything called `withResolvers()` / `withController()` risks being perceived as a “new fancy way to create a stream”, especially if it appears to bypass important guarantees.

I think the key to avoiding that footgun is to make sure this API does *not* replace or weaken any of the existing invariants:

- Backpressure semantics remain unchanged.
- `enqueue()`, `close()`, and `error()` continue to throw and fail fast.
- The API does not provide any new way to produce data that isn’t already possible today.

In that sense, this wouldn’t be a more powerful way to create streams, just a more *explicit* one. It mainly exposes information (e.g. observable completion state) or wiring that already exists implicitly in the constructor + underlying source model.

I also think positioning matters a lot here. If this is framed as a low-level, opt-in convenience for advanced producer patterns (where producer and consumer lifetimes are intentionally decoupled), rather than as a recommended default, that helps reduce accidental misuse. Putting observable state on `ReadableStreamDefaultController` itself might also help, since it avoids introducing a “new way” to create streams and instead makes existing behavior more explicit.

So I agree the bar should be high — but I think the way to clear it is by ensuring the API only makes intent and state observable, without changing the fundamental safety properties that Streams already enforce.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/streams/issues/1359#issuecomment-3823544115
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/streams/issues/1359/3823544115@github.com>