Allow `FieldsOf` to provide a pointer type

[alethenorio]

Is your feature request related to a problem? Please describe.

I am trying to wire a non-pointer field from a struct to a provider which requires a pointer of the same type

Consider the following

type Config struct {
    UserConfig UserConfig
}

func initialize(ctx context.Context, cfg *Config) (*st, func(), error) {
    panic( // panic to be replaced by generated code
        wire.Build(
            InitializeUser,
            wire.FieldsOf(new(Config), "UserConfig"),
        ),
    )
}

func InitializeUser(config *UserConfig) *User {
    // initialize user from user config
}

I am unable to wire the UserConfig field in my Config for the InitializeUser provider without writing a wrapper provider by hand.

Describe the solution you'd like

FieldsOf should provide both a non-pointer and a pointer type of that field. This seems to already be done today by the Struct Providers as per the documentation. It would be useful (and consistent) if FieldsOf would do the same

Describe alternatives you've considered

The alternative it to write your own simple wrapper provider such as

func InitializeUserConfig(cfg *Config) *UserConfig {
   return &cfg.UserConfig
}

[vangent]

Seems reasonable to me.

One option would be to make FieldsOf always provide both the base field type and a pointer to it.
This is simpler to use, but might result in type conflicts, i.e., type Foo was provided by a FieldsOf before, and *Foo was provided from somewhere else, now FieldsOf provides both and results in an error. This seems unlikely but possible.

Another option would be to add some syntax, e.g., wire.FieldsOf(new(Config), "&UserConfig") to provide a *UserConfig instead of a UserConfig.

@shantuo @zombiezen thoughts?

[alethenorio]

The issue with FieldsOf providing a pointer which is provided somewhere else is no different than attempting to provide Foo both through a FieldsOf provider and a "normal" provider right?
Coincidentally enough I also tried using the "&UserConfig" notation when trying to figure out why I wouldn't get a pointer with no luck so the idea is valid as well

[shantuo]

Option 1) SGTM, which is what we do in the struct provider now.

[zombiezen]

(Sorry, meant to get to this over the weekend but I fell ill.)

I think either of the options is fine, but I think that is important that the pointer variant is only allowed if the provided struct is of a pointer type. So this would work:

// Provides *UserConfig given a *Config
wire.FieldsOf(new(*Config), "UserConfig")

but this shouldn't:

// Does not provide *UserConfig.
// Provides a UserConfig given a Config.
wire.FieldsOf(new(Config), "UserConfig")

Reason being, it would be incorrect for the address of the field to be nondeterministic (addressing from a temporary), versus having a stable address expression.

[vangent]

Good point @zombiezen . I'll send a PR to limit the pointer-to-field to cases where the struct type is a pointer to a struct.