The documentation previously used C style enumerations: 0, 1, 2.
While this is pretty much universally correct, it does not help a user
become aware of the existence of the SeekStart, SeekCurrent, and SeekEnd
constants. Thus, we should use them in the documentation to direct people's
attention to them.
Updates #6885
Change-Id: I44b5e78d41601c68a0a1c96428c853df53981d52
Reviewed-on: https://go-review.googlesource.com/23551
Reviewed-by: Andrew Gerrand <adg@golang.org>
It's not clear we want to enshrine an io interface in which Size cannot
return an error. Because this requires more thought before committing
to the API, remove from Go 1.7.
Fixes#15818.
Change-Id: Ic4138ffb0e033030145a12d33f78078350a8381f
Reviewed-on: https://go-review.googlesource.com/23392
Reviewed-by: Austin Clements <austin@google.com>
Run-TryBot: Russ Cox <rsc@golang.org>
CL/19862 (f79b50b8d5) recently introduced the constants
SeekStart, SeekCurrent, and SeekEnd to the io package. We should use these constants
consistently throughout the code base.
Updates #15269
Change-Id: If7fcaca7676e4a51f588528f5ced28220d9639a2
Reviewed-on: https://go-review.googlesource.com/22097
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Joe Tsai <joetsai@digital-static.net>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This is a proposal. The old name is pretty poor. The new one describes
it better and may be easier to remember. It does not start with Read,
though I think that inconsistency is worthwhile.
Reworded the comment a bit for clarity.
Change-Id: Icb4f9c663cc68958e0363d7ff78a0b29cc521f98
Reviewed-on: https://go-review.googlesource.com/21629
Reviewed-by: Andrew Gerrand <adg@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
ReadAtSizer is a common abstraction for a stateless,
concurrently-readable fixed number of bytes.
This interface has existed in various codebases for over 3 years (previously
usually named SizeReaderAt). It is used inside Google in dl.google.com
(mentioned in https://talks.golang.org/2013/oscon-dl.slide) and other
packages. It is used in Camlistore, in Juju, in the Google API Go client, in
github.com/nightlyone/views, and 33 other pages of Github search results.
It is implemented by io.SectionReader, bytes.Reader, strings.Reader, etc.
Time to finally promote this interface to the standard library and give it a
standard name, blessing it as best practice.
Updates #7263
Updates #14889
Change-Id: Id28c0cafa7d2d37e8887c54708b5daf1b11c83ea
Reviewed-on: https://go-review.googlesource.com/21492
Reviewed-by: Rob Pike <r@golang.org>
The tree's pretty inconsistent about single space vs double space
after a period in documentation. Make it consistently a single space,
per earlier decisions. This means contributors won't be confused by
misleading precedence.
This CL doesn't use go/doc to parse. It only addresses // comments.
It was generated with:
$ perl -i -npe 's,^(\s*// .+[a-z]\.) +([A-Z]),$1 $2,' $(git grep -l -E '^\s*//(.+\.) +([A-Z])')
$ go test go/doc -update
Change-Id: Iccdb99c37c797ef1f804a94b22ba5ee4b500c4f7
Reviewed-on: https://go-review.googlesource.com/20022
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Dave Day <djd@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Named returned values should only be used on public funcs and methods
when it contributes to the documentation.
Named return values should not be used if they're only saving the
programmer a few lines of code inside the body of the function,
especially if that means there's stutter in the documentation or it
was only there so the programmer could use a naked return
statement. (Naked returns should not be used except in very small
functions)
This change is a manual audit & cleanup of public func signatures.
Signatures were not changed if:
* the func was private (wouldn't be in public godoc)
* the documentation referenced it
* the named return value was an interesting name. (i.e. it wasn't
simply stutter, repeating the name of the type)
There should be no changes in behavior. (At least: none intended)
Change-Id: I3472ef49619678fe786e5e0994bdf2d9de76d109
Reviewed-on: https://go-review.googlesource.com/20024
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Andrew Gerrand <adg@golang.org>
Let C be whether c valid
Let E be whether err is non-nil
The old comment explicitly says that (~C → E). However, that does call
into question whether (E → ~C), which causes doubts for users.
Without a comment at all, it is obvious that only (E ↔ ~C) makes sense.
Fixes#11308
Change-Id: I5a7d51ceb509057eccca91f57a7e48c9d1c6d112
Reviewed-on: https://go-review.googlesource.com/15256
Reviewed-by: Andrew Gerrand <adg@golang.org>
The later part of the docstring simply talks about "offset" but does
not disambiguate what it is relative to. For both the return value
and valid offsets to seek to, it only makes sense in the context of
"offset relative to origin of file".
Fixes#11877
Change-Id: Ic238a407cf8e8fdd64991d98a6584cdc8a51cd6b
Reviewed-on: https://go-review.googlesource.com/15257
Reviewed-by: Andrew Gerrand <adg@golang.org>
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>
