go - 多态地使用匿名函数传递

Question

关闭。这个问题是opinion-based .它目前不接受答案。












想改进这个问题？更新问题，以便 editing this post 可以用事实和引用来回答它.

2年前关闭。




Improve this question




据我所知，当将一个函数作为输入传递给另一个函数时，它必须具有相同的合约——不允许使用如下接口(interface):(此处可运行示例:https://play.golang.org/p/LXvNgziDdgp)

package main


func main() {
    foo(processS1)
}

type I1 interface {
    bar()
}

type S1 struct {
}

func (s1 S1) bar() {
}

func processS1(s S1) {
}

func foo(func(I1)) {
}

从类型系统的角度来看，假设的问题是传递的是函数类型，而不是接口(interface)。但是，我看不出允许类型系统在这里推断关系会有什么问题。我相信我已经在其他语言中看到了这一点。

为什么 Go 不能/不会支持这一点的任何原因？

Answer 1

简而言之，您在那里定义的关系在任何类型的语言中都无效。

您已将 foo 定义为采用 func(I1) 类型的函数。 func(S1) 是一种不同的类型。这些类型之间关系的复杂性比简单的继承更复杂。 golang 团队选择了简单而不是解决函数类型和签名匹配。

这些复杂性变得明显的一种方式是您实际上已经向后定义了关系。想象一下，有一个结构 s2 也实现了 I1。此外，s1 有一个方法 baz()。

如果 foo 将 S2{} 传递给函数参数，它将实现 I1，但 processS1 将调用传入结构中不存在的函数。

可运行:https://play.golang.org/p/EvwQpCXhqTb

即使您交换了可以在没有 panic 的情况下运行的类型( https://play.golang.org/p/ItUx5pRJ6-g )，它仍然无法在 golang 中工作。至于为什么golang不尝试解决这些问题，我不确定你会得到满意的答案。团队用一般的哲学观点来回答这类问题，例如:

The simplicity of method matching is a feature of the language.

我确实认为您的问题确实有助于证明这种观点的合理性。这是一个复杂的问题，很难推理。不解决它比增加额外的复杂性更容易。