cmd/compile: typeparams: should //go:nointerface methods satisfy type parameter constraints? #47045
Labels
compiler/runtime
Issues related to the Go compiler and/or runtime.
NeedsDecision
Feedback is required from experts, contributors, and/or the community before a change can be made.
Milestone
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 withGOEXPERIMENT=fieldtrack
:What effect should
//go:nointerface
have on type parameter constraint satisfaction? Should*T
satisfy constraintI
as a type parameter constraint? How should a compiler handle: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 constraintinterface { 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
The text was updated successfully, but these errors were encountered: