Skip to content

errors: should have minimal dependency on reflectlite #54341

Not planned
@dsnet

Description

@dsnet

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.

Activity

dsnet

dsnet commented on Aug 8, 2022

@dsnet
MemberAuthor

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.

cherrymui

cherrymui commented on Aug 8, 2022

@cherrymui
Member

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.

dsnet

dsnet commented on Aug 8, 2022

@dsnet
MemberAuthor

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).

cherrymui

cherrymui commented on Aug 8, 2022

@cherrymui
Member

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.

added this to the Backlog milestone on Aug 9, 2022
added
NeedsInvestigationSomeone must examine and confirm this is a valid issue and not a duplicate of an existing one.
on Aug 9, 2022
qiulaidongfeng

qiulaidongfeng commented on Jan 7, 2024

@qiulaidongfeng
Member

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() {

}
qiulaidongfeng

qiulaidongfeng commented on Jan 11, 2024

@qiulaidongfeng
Member

See #54341 (comment) , I think this issue can be closed.
@dsnet Could you please close this issue?

ianlancetaylor

ianlancetaylor commented on Jul 10, 2024

@ianlancetaylor
Contributor

Closing based on previous comment. Please comment if you disagree. Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    NeedsInvestigationSomeone must examine and confirm this is a valid issue and not a duplicate of an existing one.

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @ianlancetaylor@dsnet@thanm@cherrymui@qiulaidongfeng

        Issue actions

          errors: should have minimal dependency on reflectlite · Issue #54341 · golang/go