Comment 1:

Labels changed: added repo-main, release-go1.4.

Comment 2:

i think making this change will needlessly complicate the docs
without any real benefit.
The docs for Reader doesn't prohibit implementations to return
non-nil error when len(p) == 0, so the suggested rewrite is
still not 100% accurate.
(IMHO, Read(nil) should be treated as a programmer error and get
a non-nil error, if not a panic, because it doesn't do anything
useful and might indicate an error in initializing the argument.)

Comment 3:

It's not Read(nil) that I'm concerned about.  It's cases like unmarshaling a binary
format with a "length" stamp, where a 0-length is valid and expected.
Consider this program:
var hdr struct{ Length uint32 }
if err := binary.Read(r, binary.BigEndian, &hdr); err != nil {
  return err
}
buf := make([]byte, hdr.Length)
_, err := io.ReadFull(r, buf)
return err
If r.Read([]byte{}) returns a non-nil error, io.ReadFull will spuriously return a
non-nil error as well.
Do you really think it's worth complicating user code in cases like this just to avoid
fixing documentation?

Comment 4:

the problem is that the existing docs doesn't guarantee 0-byte
read won't return error, so even if we change the docs now
(note, we can't just add a restriction, as it will be an API
change), you still have to check if length is zero to be sure.
Note: ReadFull won't call the Read method if len(p) is zero,
so your example is safe regardless.
http://play.golang.org/p/Hd-Adrfl_N

Comment 5:

Well, the other problem is that people see "discouraged from returning a 0-byte count"
and think they need to special-case len(p) == 0 in their own Readers (e.g. stubs used in
testing).
At best, that complicates their implementations for no good reason.

Comment 6:

Normally you do need to special case len(p) == 0 otherwise you might
have failed bound checks (for non-trivial Readers).
Also, it's "discouraged", not "prohibited"; and if you think passing
0-byte []byte is not an error, you can return 0, nil as this is your
only choice. (I think they're programmer errors so I will just let
Read panic in this case.)

Comment 7:

CL https://golang.org/cl/143100043 mentions this issue.

Comment 8:

This issue was closed by revision 3d2321f.

Status changed to Fixed.