Comment 1:

Not completely sure this is a good idea but it seems like it might be just a few lines.

Labels changed: added priority-later, go1.3, removed priority-triage.

Status changed to Accepted.

Comment 2:

Labels changed: added release-go1.3.

Comment 3:

Labels changed: removed go1.3.

Comment 4:

Labels changed: added repo-main.

Comment 5:

Markus sent https://golang.org/cl/69870051/

Comment 6:

My first summary was bogus. The new one captures the true complexity here, and also the
not-very-general nature of the proposed change. Let's postpone that CL until after Go
1.3 is out.

Labels changed: added release-go1.4, removed release-go1.3.

Comment 7 by markus@distinctive.co:

So would the preference be to have a new type of reader, like FileSectionReader for
example, that would specifically address this network use-case rather than exposing more
of the SectionReader's internal state?
If there is question of the value of this feature, our specific case streams entries to
a file and then periodically ships file chunks to a remote server in a single process,
we have seen a noticeable increase in performance by deferring to the OS/sendfile under
strained workloads.

Comment 8:

The goal is to have a consistent and simple API above all else. Performance is nice, but
not if it means adding new confusing types for rare cases. That means all readers of the
io package docs have the cognitive burden of seeing that new type and its docs and
understanding why they should or shouldn't use it.
If a new type is only for performance, and the performance is actually worth it in many
cases, and it's not something people can do on their own easily without forking lots of
code, then it's possible we could support it in more gross/magic ways.
Exposing io.LimitedReader (it used to be hidden) was already a bit of a compromise.
But now that LimitReader + sendfile works, it's unclear we need to make all the reader
wrapper types work with sendfile--- you can make a LimitReader now and use it with
ReadFrom.  If you made the SectionReader then you already have the *os.File.

Comment 9:

Sounds like we don't need this.

Status changed to WontFix.