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.

Reply via email to