This seems like a pretty major behavior change, like when people suggest garbage collecting stuck goroutines. This garbage collects a reason that a goroutine is stuck, unsticking it.

The nice thing about deadlocks and stuck goroutines is all you have to do is look at the stacks and they're right there. Why is this important to change the semantics of?

The nice thing about deadlocks and stuck goroutines is all you have to do is look at the stacks and they're right there.

That presumes that someone is actually looking for them. The reality is that even experienced Go programmers write buggy code that results in goroutine leaks which results in deadlocks or high memory consumption that can go unnoticed for a some time. It is better if such failures can be detected earlier on.

Semantic 2 proposed above would not change the behavior, but print out in race mode when a resource leak is detected.

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

The difficulty here is managing the lifetimes of the reader and writer, and ensuring that eventually one of them gets closed. In my experience, the code that calls io.Pipe in a good position to gauge that lifetime.

This suggests an alternative solution:

// PipeContext calls io.Pipe. When ctx is done, both the reader and writer are closed with the error from ctx.Err.
func PipeContext(ctx context.Context) (*io.PipeReader, *io.PipeWriter)

This can't live in package io, because dependencies.

It can be implemented straightforwardly outside of the standard library, at the cost of an additional goroutine (wrap io.Pipe) or code duplication (copy+modify io.Pipe).

Having something like it in the standard library would help with discoverability and documentation. If it existed, I'd be tempted to deprecate io.Pipe, on the grounds that it is hard to use safely.

I like the idea of PipeContext (in addition to what's proposed).

It's not clear to me that io can't depend on context, but if we wanted to break this edge, we could do:

func PipeContext(ctx interface{ Done() <-chan struct{} }) (*PipeReader, *PipeWriter)

or more simply as just:

func PipeCancelable(done <-chan struct{}) (*PipeReader, *PipeWriter)

@dsnet I think it'd have to be:

func PipeContext(ctx interface{ Done() <-chan struct{}; Err() error }) (*PipeReader, *PipeWriter)

so that the error from the context closure can be propagated to CloseWithError. That's a bit of a mouthful. :)

Change https://go.dev/cl/412955 mentions this issue: compress/gzip: always close bodyReader in Example_compressingReader

It's unclear to me that io really needed to have Pipe at all.
If we were starting over, maybe it would be better to leave it out.
Do we need to put more variants of Pipe (PipeContext, PipeCancelable) in?
Why not leave them to external packages?
An external implementation could also revisit the zero-copy / synchronous behavior of io.Pipe.
In many cases you might be happier with a buffered / async version too.

It's unclear to me that io really needed to have Pipe at all. If we were starting over, maybe it would be better to leave it out. [...] Why not leave them to external packages?

I am sympathetic to this. But this whole conversation started (over in Gopher Slack) with the need for io.Pipe to deal with lacunae in the standard library, like #51092, or hooking up json.Encoder (writer) to http.Request.Body (reader) for the common task of making an HTTP request with a JSON body.

As a result, the standard library itself needs a way to document and/or explain the correct way to write the code. See as a data point the continuing conversation at https://go-review.googlesource.com/c/go/+/412955.

Also, for core functionality, people will empirically reach for error-prone std functions over safer third party libraries. Putting io.Pipe variants in an x repo would help with the second challenge, as x has the requisite trust factor. Another way to help that sociological problem would be to "bless" a third party library by referring to it in the io.Pipe docs. I assume Google is unwilling to do that for anything but x repos.

Do we need to put more variants of Pipe (PipeContext, PipeCancelable) in?

FWIW, since contexts are cancellable, PipeContext covers PipeCancellable. :)

But yes, a buffered version would be nice to have sometimes.

(That said, if this doesn’t go into std or x in any form, I will create a third-party library that does this right, so that I can use it.)

It seems clear we need a good answer for the gzip/json/http problem, but I'm not sure io.PipeContext improves that situation dramatically, given that the 1-line change in CL 412955 makes it not needed for that. It seems like we haven't found the obviously right answer yet.

Based on the discussion above, this proposal seems like a likely decline.
— rsc for the proposal review group

No change in consensus, so declined.
— rsc for the proposal review group