printsrc: Printing Go Values as Source
There are many packages that print Go values so people can read them. This package prints Go values so the Go compiler can read them. It is intended for use in code generators.
Background
I wanted to provide some data to my program at startup. I could have used go:embed
to store the raw data with the program and process it at startup, but I wanted to pay the processing cost beforehand and generate Go data structures into a .go
file that could be linked with the rest of my code.
So I need something that printed Go values as Go source. I looked around at the many pretty-printing packages out there:
- github.com/davecgh/go-spew/spew
- github.com/k0kubun/pp/v3
- github.com/kr/pretty
- github.com/kylelemons/godebug/pretty
- github.com/sanity-io/litter
and more. They do a great job of formatting Go values for people to read. But I couldn't find one that correctly prints values as Go source. So I wrote this package.
Issues with Printing Source
Here are a few challenges that come up when trying to print Go values in a way that the compiler can understand.
Special floating-point values
Consider the floating-point value for positive infinity. There is no Go literal for this value, but it can be obtained with math.Inf(1)
. Calling fmt.Sprintf("%#v", math.Inf(1))
returns +Inf
, which is not valid Go.
The printsrc
package prints a float64
positive infinity as math.Inf(1)
and a float32
positive infinity as float32(math.Inf(1))
. It handles negative infinity and NaN similarly.
Values that cannot be represented
Function and channel values cannot be written as source using information available from the reflect
package. Pretty-printers do their best to render these values, as they should, but printsrc
fails on them so you can discover the problem quickly.
Pointers
When faced with a pointer, printers either print the address (like Go's fmt
package) or follow the pointer and print the value. Neither of those, when fed back into Go, will produce the right value. Given
i := 5
s := []*int{&i, &i}
this package will print s
as
[]*int{
func() *int { var x int = 5; return &x }(),
func() *int { var x int = 5; return &x }(),
}
That is a valid Go expression, although it doesn't preserve the sharing relationship of the original. For simplicity, printsrc
doesn't detect sharing, and fails on cycles.
Types from other packages
Say your data structure contains a time.Duration
. Depending on where it occurs, such values may have to be rendered with their type, like time.Duration(100)
. But that code won't compile unless the time
package has been imported (and imported under the name "time"). Types in the package for where the generated code lives don't have that problem; they can be generated without a qualifying package identifier.
printsrc
assumes that packages it encounters have been imported using the identifier that is the last component of their import path. Most of the time that is correct, but when it isn't you can register a different identifier with an import path.
Values that need constructors
The time.Time
type has unexported fields, so it can't be usably printed as a Go struct literal (unless the code is being generated in the time
package itself). There are many other types that need to be constructed with a function call or in some other way. Since printsrc
can't discover the constructors for these types on its own, it lets you provide custom printing functions for any type. The one for time.Time
is built in and prints a call to time.Date
. (You can override it if you want.)