go
go copied to clipboard
golang
errors: should have minimal dependency on reflectlite
On go1.19, A blank import of "errors" increases the binary size by ~15.5KiB due to the transitive dependency on reflectlite.
The hard dependency occurs because of the program initialize variable for:
var errorType = reflectlite.TypeOf((*error)(nil)).Elem()
We could consider a trick similar to 419757
This is relevant since many packages depend on errors only for errors.New, and we should not expect those packages to force reflectlite to be transitively linked in.
I also wonder if programs that depend on both reflect and reflectlite could just end up using the reflect package instead and save that ~15.5KiB. I don't know how to implement that without some linker magic.
Perhaps the reflect package can can just import reflectlite and build on top of it, instead of duplicating code. (The reflectlite package may need to export more things for reflect to use, and that is fine, as it is an internal package.)
It would look nicer if the reflect package is self-contained. But probably okay if it is not.
It would look nicer if the reflect package is self-contained. But probably okay if it is not.
For "look nicer", are you referring to how the package appears in pkgsite? Implementing "reflect" in terms of "reflectlite" will probably require the primary types to be declared in reflectlite with type aliases left in "reflect". For an unrelated package split that I was doing, @mvdan mentioned that we might want to teach the pkgsite certain patterns where it hoists a type alias as if it were declared locally (in terms of presentation).
I was mostly thinking about reading the code. It would be nicer if the code stays together.
For documentation, reflectlite doesn't define many types for reflect to export, so it is probably not too bad. We probably could alias Kind and Type, or duplicate them, which shouldn't be too bad. I don't think we can alias Value as we need to define more methods on reflect.Value. reflect.Value could probably wrap reflectlite.Value.
The issue has been settled go build the following code, with or without import errors, is 1.4M in size
package main
import _ "errors"
func main() {
}
See https://github.com/golang/go/issues/54341#issuecomment-1879968971 , I think this issue can be closed. @dsnet Could you please close this issue?