Hi, I'm not sure I understand this analyzer. In your documentation, you have the following example:

func f[T any](t T) {} // want "should not use 'any'. hint: string|~int"

func invoke() { // OK
	f("gopher")
	f(1)
	type MyInt int
	f(MyInt(18))
}

Why would the user want to restrict this function to to string|~int when it's not necessary? If any is sufficient for the algorithms implemented by a generic type/function, then the user should use any to make their code as "generic" as possible.

Hi, it is true that there is no way to determine whether the any is intentional or not now.

How about adding the following option to determine if the any is necessary?

• not exported
• not comment like // no gencon lint

If this option is added, users can choose any intentionally.

My idea:

func e[T any](t T) {} // want "should not use 'any'. hint: string|~int"

// no gencon lint
func f[T, U any, V int](t T, u U, v V) {} // OK(because there is the comment)

func g(s string) {} // OK

func H[T any](t T) {} // OK(because this is exported)

func invoke() { // OK
	e("gopher")
	e(1)
	type MyInt int
	e(MyInt(18))

	f(3, "gopher", 100)
	f(true, MyInt(3), 100)

	g("gopher")
}

Typically, constraints should specify the minimum number of restrictions required for the function body.

Consider the equivalent logic for interfaces

func f(x interface{m()}) {
  m()
}

func _(x interface{ a(); m() ) {
  f(x)
} 

Just because f is only called with values that have a() doesn't mean we should add a() to the type of x. Doing so does not add value: it only restricts the places in which f could be called.

In your example, what advantage does changing the constraint to string|~int add? As far as I can tell this only restricts the function so that in the future if one wanted to call it with, say []byte, one would have to modify the definition of f.

So if we can choose any for type constraints, we should use any to make the function most generic , right?
I somehow thought we should avoid using any.
Thanks for your explanation!!