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

irlmq6kh  于 4个月前  发布在  Go
关注(0)|答案(4)|浏览(38)

"fieldtrack"实验包括一个//go:nointerface指令,表示不应将方法视为接口满足性。例如,这个包在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

//go:nointerface应该对类型参数约束满足性产生什么影响?*T是否应作为类型参数约束满足I?编译器应如何处理:

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正式只是一个实验,因此我认为支持任何一方(即,如果允许,则接受并正确处理,如果不允许,则始终拒绝)都不是紧急的。我还认为我们有权改变我们对此行为的看法。但似乎值得确保我们在长期方向上基本一致。
我目前倾向于认为,如果(*T).M//go:nointerface,则*T不满足约束interface { M() }。(这在cmd/compile中实现起来有点麻烦,因为目前types2负责约束满足性,但它不知道像//go:nointerface这样的指令;但我认为处理起来不应该那么困难。)
/cc @griesemer@ianlancetaylor@findleyr

ppcbkaq5

ppcbkaq51#

https://golang.org/cl/332611提到了这个问题:[dev.typeparams] cmd/compile: fix unified IR support for //go:nointerface

6mzjoqzu

6mzjoqzu2#

我认为我们不知道go:nointerface应该对约束做些什么。转到1.19里程碑。

wpcxdonn

wpcxdonn3#

由于类型参数约束只是接口,我认为没有接口方法不满足它们,就像它们不满足常规接口一样。

gojuced7

gojuced74#

将文本内容移动到待办事项列表中。

相关问题