Sounds reasonable, given that there's no simple way to currently work around buffering all the data in memory.

I wonder how often this comes up, though. I've used templates for multiple years and I've never had the need to print an io.Reader with them. Do you have example use cases?

/cc @robpike @rogpeppe

Sadly, none that I can link, but I've encountered this problem in several situations, mostly because I dealt a lot with net conns and external data sources that my code was just transforming (wrapping readers).

I ended up writing my own kind of templates that interleaved (*text.Template).Execute calls with io.Copy calls.

I just found the previous bug and created a small patch to support this use case for me and other people that might incur in the same issue.

Also, since most of the stdlib passes io.Readers around, it just seemed more natural and fitting to print the content of the reader instead of the reflection of its fields values, which seems like a very edge case for templates.

I've re-purposed this to be a proposal, in hopes that the proposal team can make a decision.

I still think this is reasonable, though I haven't encountered the use case directly. It doesn't add any new API, and shouldn't break any existing templates. So I lean towards doing this, since none of the other template owners have spoken up.

/cc @robpike

Trying to do this in the template language seems quite complex. Maybe {{.}} makes sense to copy directly, but what about ``{{. | printf "%q"}}`? That would still have to buffer. There are a lot of API implications here, so it really is "new API".

Getting back to:

tpl := template.Must(template.New("").Parse("{{.}}"))
tpl.Execute(os.Stdout, strings.NewReader("gopher"))

If the template does no buffering of its own, or if we gave a way to flush the buffer, then you could define your own "copy" function that copies a reader to stdout and write {{copy .}} instead. Would that work?

Probably defining a copy function would solve the problem, but how would you pass the current io.Writer the template is rendering to?

I talked to @robpike (owner of text/template) about this a while back, and we weren't entirely sure about the implications. I'm still not. The current CL handles an io.Reader coming out of the end of execute, but what would that mean for html/template? Does html/template have to have streaming escaping converters? Should anything else change?

Does anyone want to write down the specific documentation changes that would describe the proposed change? Note that CL 25160 exempts Readers that are also Stringers or errors from being read, and I don't quite understand why.

Existing templates may also be affected unexpectedly. Perhaps a design doc is warranted here.

I ended up doing something like this, basically passing the output writer to the template and wrapping io.Copy in a helper.

The more I think about embedding this behavior in the templating language the less I'm convinced about it. I just wonder if template uses some internal buffering that might cause my workaround to break.

Closing as this can be done with current templates and adding helpers to simplify it would significantly complicate things.

Thanks for working on this.