Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal: text/template: add support for io.Reader #29165

empijei opened this Issue Dec 9, 2018 · 4 comments


None yet
6 participants
Copy link

empijei commented Dec 9, 2018

What version of Go are you using (go version)?

$ go version
go version go1.9.4 linux/amd64

Does this issue reproduce with the latest release?


What operating system and processor architecture are you using (go env)?

go env Output
$ go env
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build114129408=/tmp/go-build -gno-record-gcc-switches"

What did you do?

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

What did you expect to see?


What did you see instead?

"{gopher 0 -1}"


Most IO operations in go are executed on io.ReadWriters and it is very frequent to open streams, pass them around, wrap them and so on, all the way from data sources to data sinks.

One exception to this rule seems to be templates: the only way to take some text blob from a file and output it in the template is to copy the entire file in a string and then pass the string to Execute.

It would be nice to be able to use io.Readers with templates and avoid the unnecessary buffering.

A CL for the proposed change can be found here.

A previous bug mentioning this need: #25160.


This comment has been minimized.

Copy link

mvdan commented Dec 9, 2018

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

@mvdan mvdan added the NeedsDecision label Dec 9, 2018


This comment has been minimized.

Copy link
Contributor Author

empijei commented Dec 9, 2018

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.

@ianlancetaylor ianlancetaylor added this to the Go1.13 milestone Dec 10, 2018

@mvdan mvdan changed the title text/template: add support for io.Reader Proposal: text/template: add support for io.Reader Mar 28, 2019

@gopherbot gopherbot added the Proposal label Mar 28, 2019

@mvdan mvdan modified the milestones: Go1.13, Proposal Mar 28, 2019


This comment has been minimized.

Copy link

mvdan commented Mar 28, 2019

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.


This comment has been minimized.

Copy link

andybons commented Apr 17, 2019

/cc @robpike

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.