To be clear, you mean a bytes.Reader value and not a nil *bytes.Reader pointer, right? (Because it's the pointer type that implements io.Reader, etc.)

So you mean that a (perhaps implicit) pointer to a zero-value bytes.Reader should act like a bytes.NewReader(nil)?

If so, that might be okay (if we also do strings.Reader), but I would object to making a nil pointer act like an always-EOF reader.

Yes, correct, a zero bytes.Reader value, not a nil pointer. The idea is to avoid initialization of a bytes.Reader field, like bytes.Buffer and sync.Mutex allow.

The zero value for Buffer is an empty buffer ready to use.

The zero value for a Mutex is an unlocked mutex.

Looks like strings.Reader can be adapted just as easily.

We should definitely make new(bytes.Reader) and bytes.NewReader(nil) behave identically. There's no need to redefine prevRune necessarily - there's enough other info in the struct to understand that there is no previous (i==0 for example). It looks like UnreadRune just needs the same 3-line if statement as in UnreadByte added to it (not replacing the existing if statement, which is something else).

Marking accepted from an API point of view.

Change https://golang.org/cl/145098 mentions this issue: bytes: fix Reader.UnreadRune returning without error on a zero Reader

Change https://golang.org/cl/145737 mentions this issue: crypto/tls: remove unneeded calls to bytes.NewReader