The "fieldtrack" experiment includes a //go:nointerface directive, which says a method shouldn't be considered for interface satisfiability. For example, this package fails to compile with GOEXPERIMENT=fieldtrack:

package p

type T int

//go:nointerface
func (*T) M() {}

type I interface { M() }

var i I = new(T) // ERROR: *T does not implement I, because (*T).M is marked //go:nointerface

What effect should //go:nointerface have on type parameter constraint satisfaction? Should *T satisfy constraint I as a type parameter constraint? How should a compiler handle:

package p

type T int

//go:nointerface
func (*T) M() {}

type I interface { M() }

func F[X I]() {
  var _ I = new(X)
}

var _ = F[T]

Fieldtracking is formally just an experiment, so I don't think it's urgent to support either way (i.e., either to accept and handle correctly if it's allowed, or to consistently reject if it's not allowed). I also think we reserve the right to change our mind on the right behavior here. But it seems worth making sure we're more-or-less on the same page about long-term direction here.

I'm currently inclined to think *T does not satisfy constraint interface { M() } if (*T).M is //go:nointerface. (This is a bit bothersome to implement in cmd/compile, because currently types2 is responsible for constraint satisfaction, but it doesn't know about directives like //go:nointerface; but I don't think it should be that hard to handle.)

/cc @griesemer @ianlancetaylor @findleyr