If the io.ReadCloser contains a noopCloser, that is.

This is true. What's the larger problem? We're unlikely to export this.

I came across this while writing some tests for code that made http
requests, and I wanted to inspect the request bodies, which were
bytes.Buffer instances (underneed the nopCloser). In this case, I can read
the data out and inspect that.

But, it seems odd to have a type that adds a noop method and obscures the
underlying type, for seemingly no reason beyond a default stance of not
exporting things (which is a good default stance).

On Thu, Aug 20, 2015 at 4:07 PM, Brad Fitzpatrick notifications@github.com
wrote:

This is true. What's the larger problem? We're unlikely to export this.

—
Reply to this email directly or view it on GitHub
#12235 (comment).

I often hide stuff in anonymous structs or unexported things on purpose so I can use some implementation (like a *bytes.Buffer) myself but not leak that detail across package boundaries, so I don't have to be locked in to that implementation, and have people messing with internals (e.g. *bytes.Buffer.Bytes() []byte and mutating it)

I think this is working as intended, or at least nothing to do.