Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/compile: typeparams: should //go:nointerface methods satisfy type parameter constraints? #47045

mdempsky opened this issue Jul 3, 2021 · 3 comments


Copy link

@mdempsky mdempsky commented Jul 3, 2021

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

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

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

@mdempsky mdempsky added the NeedsDecision label Jul 3, 2021
@mdempsky mdempsky added this to the Go1.18 milestone Jul 3, 2021
Copy link

@gopherbot gopherbot commented Jul 3, 2021

Change mentions this issue: [dev.typeparams] cmd/compile: fix unified IR support for //go:nointerface

gopherbot pushed a commit that referenced this issue Jul 26, 2021

This CL changes fixedbugs/issue30862.go into a "runindir" test so that
it can use '-goexperiment fieldtrack' and test that //go:nointerface
works with cmd/compile. In particular, this revealed that -G=3 and
unified IR did not handle it correctly.

This CL also fixes unified IR's support for //go:nointerface and adds
a test that checks that //go:nointerface, promoted methods, and
generics all interact as expected.

Updates #47045.

Change-Id: Ib8acff8ae18bf124520d00c98e8915699cba2abd
Run-TryBot: Matthew Dempsky <>
TryBot-Result: Go Bot <>
Trust: Matthew Dempsky <>
Reviewed-by: Robert Griesemer <>
Copy link

@ianlancetaylor ianlancetaylor commented Jan 28, 2022

I don't think we know what go:nointerface should do for constraints. Moving to 1.19 milestone.

@ianlancetaylor ianlancetaylor removed this from the Go1.18 milestone Jan 28, 2022
@ianlancetaylor ianlancetaylor added this to the Go1.19 milestone Jan 28, 2022
Copy link

@cherrymui cherrymui commented May 18, 2022

Since type parameter constraints are just interfaces, I'd think nointerface methods don't satisfy them, just like they don't satisfy regular interfaces.

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

No branches or pull requests

4 participants