The io.WriterTo interface has come up in a code review discussion.
```
// WriterTo is the interface that wraps the WriteTo method.
//
// WriteTo writes data to w until there's no more data to write or
// when an error occurs. The return value n is the number of bytes
// written. Any error encountered during the write is also returned.
//
// The Copy function uses WriterTo if available.
type WriterTo interface {
WriteTo(w Writer) (n int64, err error)
}
```
Should WriteTo always modify receiver state, updating its internal "file
position" by the number of bytes written?
Equivalently, if I'm re-using a WriterTo, passing it to multiple Copy
calls, would you expect to need Seek(0, SeekStart) calls in between those
Copy calls? This is a question of clarifying semantics. The compiler
doesn't complain if WriteTo always wrote the entire contents (and didn't
have a "file position").
---
In the standard library, every WriterTo implementation (with one
exception), listed below, also "advances the file position". They all also
implement io.Reader, even though, once again, the compiler doesn't enforce
that every io.WriterTo is an io.Reader.
archive/tar.regFileReader
archive/tar.sparseFileReader
bufio.Reader
bytes.Buffer
bytes.Reader
net.Buffers
strings.Reader
There's also net/http.noBody, which doesn't explicitly update a "file
position" field but it also represents a 0-sized "file" so in some sense
it's always at the "end of the file".
The one exception is recordingConn in crypto/tls/handshake_test.go but it
looks like its WriteTo method is more about "dump some debugging
information" (it's in *_test.go code) than anything related to io.Copy.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CAOeFMNXaQGic%3DYxJV64z%2BoWPMk7c4m1WR2%3Di4gTEGJOxwRq3OQ%40mail.gmail.com.
