wire: UX can be better by supporting argument name matching warning during `wire check`

[garukun]

Problem

Considering the following scenario:

// in app.go
type Agent1 struct {
  name string
}

type Agent2 struct {
  version string
}

type Server struct {
 A1 Agent1
 A2 Agent2
}

var set  = wire.NewSet(provideServer, provideAgent1, provideAgent2)

func provideServer(a1 *Agent1, a2 *Agent2) *Server {
  return &Server{A1: a1, A2: a2}
}

func provideAgent1(name string) *Agent1 {
  return  &App{name: name}
}

func provideAgent2(version string) *Agent2 {
  return &Agent{version: version}
}

// in injector.go
func Initialize(name string) {
  wire.Build(set)
}

wire check and wire gen completes just fine. While by the argument name, name and version means different things, both will actually be injected with the value of name. While I believe this is a user error and can be fixed using named types, UX can improve here.

Suggestion

While running wire check or wire gen, in addition to checking for colliding data types, also checks for distinct parameter names on colliding data types. In the added case, we output a warning message (with suggestions to use type alias) while allowing the code generation to complete.

[zombiezen]

Interesting idea. While I do think it would be difficult to determine whether a differing parameter name has semantic meaning as to how it's being interpreted, it could be interesting to emit warnings if a graph contains common built-in types. Perhaps a wire lint command that encourages best practices.

[garukun]

Thanks for replying! Warning on built-in types would be awesome as well.

Meanwhile, I feel like wire check and wire lint can create some confusions. While I did not dive too much into the implementation details of wire check. Based on the commentary:

// check runs the check subcommand.
//
// Given one or more packages, check will print any type-checking or
// Wire errors found with top-level variable provider sets or injector
// functions.

There can be some redundancy in wire gen, wire check, and wire lint. A particular development flow can feel like:

Hack, hack, hack, is my code working and stylist?

$ wire lint
$ wire check

_ hack hack hack_

$ wire lint
$ wire check
$ wire gen

The repeated wire lint and wire check can get a bit tiring. Maybe #62 is a prerequisite to this issue.

[zombiezen]

Yup, docs explaining the purpose of each of these commands would definitely help. FWIW, wire check is mostly helpful for libraries where you are creating provider sets that aren't going to be used in any injector. For an application, wire [gen] is all you need.

And for the record, wire lint might not be the right approach. I'm not exactly sure what is; I'll have to think on this issue for a while.