On Wed, Oct 26, 2022 at 8:14 PM Nigel Tao <nigel...@golang.org> wrote: > > 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?
I think that should be the default behavior, yes. Of course there may be cases where that doesn't make sense. But in general I expect WriteTo to behave like one or more calls to Read. > 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"). Yes, I would expect that for cases where the WriterTo is seekable. My reason for thinking this is that WriteTo basically exists to support io.Copy, and in the absence of WriteTo io.Copy does advance the file position of the source. So I think that for WriteTo to also behave that way is the least astonishing choice. Ian -- 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/CAOyqgcWBMo8P7wCzJZA3yfpZX2imVutZdfQ-xkU%3DfoCJyzEYnA%40mail.gmail.com.