Re: [whatwg/streams] Note about underlyingSink close() method is misleading (#617)

This made me think that it might make more sense if we change the place of "fallback" from `WritableStreamDefaultControllerAbort()` to `WritableStreamDefaultControllerProcessClose()`, and change the "fallback" to be invocation of `underlyingSink.abort()` in absence of `underlyingSink.close()`.

As ricea said, `underlyingSink.close()`'s semantics change depending on presence of `underlyingSink.abort()`. If we change this to be what I suggested above:
- developers would implement `underlyingSink.close()` if they want to notified only when all `write()`s completed successfully,
- or implement only `underlyingSink.abort()` if they're not interested in the distinction. Treating `writer.close()` with `underlyingSink.abort()` looks weird, but it's also weird that we're handling `writer.abort()` with `underlyingSink.close()` in absence of `underlyingSink.abort()`.

> close() can also be called while an existing async call to close() is already in progress, but that might be a spec bug.

Agreed. When only `close()` is implemented, the implementation should be doing something common for  both `writer.close()` and `writer.abort()`. It doesn't make sense to call it twice. They can still switch the behavior for the first and second invocation, but they should then just implement `close()` and `abort()` instead.

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