Comment 1:

IMO not necessary. Status quo (same concept as when io.Reader returns err != nil) may be
confusing while not reading the docs carefully enough, but it makes for simpler
implementation, I think and the client code can use the same logic as when reading from
an io.Reader.

Comment 2:

I think we don't need to think about the complexity of ReadFull and ReadAtLeast, because
it's only implemented once.
I'm more concerned about the complexity of their use.
I think lots of Go programs (if not all) all treat non-nil err returned from
ReadFull/ReadAtLeast
as fatal without paying attention to the n returned.
http://tip.golang.org/search?q=_%2C+err+%3A%3D+io.ReadFull
shows that there are 52 uses of "_, err := io.ReadFull", which makes this assumption.
If we choose to maintain the status quo, we should fix all of them (except tests,
perhaps,
but please note that of the 52 occurrences, only 9 of them are in package tests).
On the contrary, I've tried to fix ReadFull and ReadAtLeast, and one package test failed
because, so this might not be backward compatible change (though I argue that they
depend on undocumented feature of ReadFull/ReadAtLeast, and we can ignore them).

Comment 3:

@2: Wow, 52 errors in the stdlib? No, I was mistaken: `ReadFull` does not behave in the
same way as `io.Reader.Read` (wrt io.EOF) and it is documented correctly. My bad.

Comment 4:

they are potential errors and only misbehave for a very specific kind of io.Readers.
(which returns len(buf) and err where err != nil && err != io.EOF)
we do have some "bad" io.Reader implementations available in testing/iotest, but
not many io.Reader users are tested against them.

Comment 5:

This issue was closed by revision 662ff54.

Status changed to Fixed.