What you are asking for is not race safe.

If you want to implement this logic, insert your own type between bufio and net Conn. Then you have the hooks to reopen network connections as you desire.

If you want to implement this logic, insert your own type between bufio and net Conn. Then you have the hooks to reopen network connections as you desire.

That results in one extra data copy which I'm trying to avoid.

Btw, I don’t think this will be reliable because data may be lost between the sender and receiver in such a way that you cannot correctly determine the number of bytes received so you can correctly rewind the writer. This problem of distributed coordination is considered non trivial.

If you want to implement this logic, insert your own type between bufio and net Conn. Then you have the hooks to reopen network connections as you desire.

That results in one extra data copy which I'm trying to avoid.

I don’t believe this is correct. io.Writer does not require intermediaries to buffer data.

If you want to implement this logic, insert your own type between bufio and net Conn. Then you have the hooks to reopen network connections as you desire.

That results in one extra data copy which I'm trying to avoid.

I don’t believe this is correct. io.Writer does not require intermediaries to buffer data.

The thing is, there is already some unflushed buffered data in bw.buf, how can I migrate it to a new io.Writer like bytes.Writer?

I don’t think think you need to module bufio to do what you’re asking. I also think what you are asking is unsound because tcp will lie to you. I think you can prove this to yourself, or prove me wrong, with an straight net.Conn. If you can build a wrapper type that can handle the underlying net.Conn going away and being reconnected, then wrapping a bufio Writer around that whole thing for convenience can be done afterwards.

Let's just put the TCP aside, I still think that bufio.Writer outght to allow users to retain buffered data when switching the underlying io.Writer, for some scenarios.

Discarding all buffered data is also unsound to me from where I stand.

Maybe, but why should the ability to switch underlying writers be restricted to just bufio? That feels like the domain of a different type which itself implements io.writer

In case you didn't notice, actually bufio.Writer itself is already a wrapper of io.Writer, thus it's rational to ask it to evolve more abilities.

It just really bothers me that bufio allows users to switch the underlying io.Writer of bufio.Writer (by bufio.Reset(w)) and yet forbids them to do so while retaining unflushed buffered data.

I agree with @davecheney : write your own type that does what you need. There is nothing particularly special about bufio.Writer. What you are looking for seems very special purpose.

My case might be specific, but it should be all-purpose for a new method that is like Reset() but retains buffered data. I only brought my case out for illustrating the requirement and I believe there are more scenarios.

Change https://golang.org/cl/329569 mentions this issue: bufio: add a new method "Handover" for Writer and Reader

As others have noted, the easy way to do this is to make your own Reader/Writer implementation that you pass to bufio.

type SwappableWriter struct {
	io.Writer
}

sw := &SwappableWriter{c}
b := bufio.NewWriter(sw)
b.Write(whatever)
sw.Writer = newC // "Handover"

There is literally no code required, just a type declaration.
This is incredibly specialized and does not seem worth complicating the bufio API for.

Thank you @rsc for the solution which is actually similar to my current implementation, I just come here to ask for opinions from the Go team about adding this ability to bufio, still, the case I've given above might be specific, but it should be all-purpose for a new method that is like Reset() but retains buffered data since bufio.Writer is already a wrapper for io.Writer.

Thanks again for your advices and time.

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

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