I think this has the same meaning as before,
but the text is tighter, and it makes some people happy.
Fixes#10182.
Change-Id: I7ee1eae4bcd6ee4a5898ea948648939e6bde5f01
Reviewed-on: https://go-review.googlesource.com/11674
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
This trivial addition to the io package makes it easy to control the
buffer size and allocation properties of io.Copy.
Change-Id: Ica1a6bd015e429d4e655bc0c6f66cea21c454acf
Reviewed-on: https://go-review.googlesource.com/8730
Reviewed-by: Russ Cox <rsc@golang.org>
"returns ... the first error" was misleading or at least confusing:
in case a Read results in an error with non-zero bytes read, and the
subsequent Write also results in an error, the error from Write is
returned, which is the second one (in the temporal dimension).
Fixes#9744
Change-Id: If8925a701e4fae820cd9df7446503403fc0785d4
Reviewed-on: https://go-review.googlesource.com/3686
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The previous wording implied that reads would return no error, rather
than EOF. It's convenient for users to know that Close() is equivalent
to CloseWithError(nil) because it can remove a branch from their error
handling code where they want to close the pipe in the appropriate way.
For example:
6e9a8cec0a/gcs/bucket.go (L637-L643)
Change-Id: I618bffe556eb518011e7ba5cdce1eb0ff536350e
Reviewed-on: https://go-review.googlesource.com/8152
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
