Go 的“类型断言”方式背后的原因是什么？

问题内容

我试图理解这样一个事实：golang 的类型断言仅适用于显式定义为接口类型的变量，不适用于具体类型（即“string”、“int32”）等..）。

这是一个快速而简单的代码示例，它说明了我困惑的根本原因：

package main

import "fmt"

// here we define an interface type:
type Shape interface {
    DoubleSize() int32
}

// here we define a new type which is really just an int32:
type Rect int32

// here we make "Rect" type above comply with the "Shape" interface by implementing the methods of that interface
// and so, since the interfaces in Go are implemented implicitly, this should make the "Rect" type an implicit instance of the "Shape" interface
func (theShape Rect) DoubleSize() int32 {
    return int32(theShape) * 2
}

// this function expects its "someShape" parameter to be of "Shape" type (or "the type that quacks like "Shape" interface does))
func whateverFunction(someShape Shape) int32 {
    return someShape.DoubleSize()
}

func main() {
    var newRect = Rect(5)
    // ^^ if this is instead written as "var newRect Shape = Rect(5)" no error with type assertion happens down the line

    whateverFunction(newRect) // the function works just fine because "newRect" implicitly implements the "Shape" interface — the one that this function expects to receive.  

    // !! but type assertion doesn't work on "newRect"
    v, ok := newRect.(Shape) // error: invalid operation: newRect (variable of type Rect) is not an interface
    if !ok {
        fmt.Println("type assertion failed")
        return
    }
    fmt.Println("This is v:", v)
}

正如这个问题的标题所暗示的，我无法理解实现类型断言仅适用于接口类型背后的推理，并检查分配给显式实现该接口的变量的基础值是否是我们在内部指定的值“.(t)”断言方法。这让我觉得“类型断言”是一个无意的用词不当，意味着它适用于所有类型，但不适用于，仅适用于接口类型。

我的意思是，这个语言设计决策背后显然一定有一个原因，我认为这可能与惯用的 golang 的编写方式有关，但尽管我已经看到了关于这个问题的大量资源，他们从未具体说明原因。

对我来说有意义的原因是，如果 go 程序应该“最好（我假设，因为显式接口定义是可选的）”，用表示某些接口（行为）的所有变量编写，因此定义一个出于清晰性和可读性的目的，变量上的显式接口是有意义的。

但正如我所提到的，我从未见过任何资源具体说明为什么“类型断言”功能是如何在 go 中实现的，我希望您能帮助我澄清这种困惑。

-- upd 1 - 添加一些内容来澄清我的问题：

我认为，我的核心问题是关于原因（我不明白）类型断言仅在显式实现变量的接口时才起作用，而在隐式实现接口时则不起作用。

正如“whateverfunction”所演示的，代码确实考虑“newrect”来实现“shape”接口，或者“成为“shape”接口的实现”（否则该函数将不会不适用于该变量，但确实如此），但类型断言“.(t)”方法背后的代码不将“newrect”视为“shape”接口的实现。

因此，如果 golang 中关于接口实现的考虑因素存在差异，我认为这样的设计决策背后一定有一个原因（区分）。

这就是为什么我提到到目前为止我能想到的唯一原因是这是否是一种让人们以某种​​方式编写 go 代码的方法。

正确答案

您可以查看Burak Serdar的答案 - 您可能会发现它更加简洁和有帮助。尽管如此，我还是会发布整个推理链，最终让我“点击”了它：

|-> 当我们无法确定我们期望接收的数据的确切类型时，使用接口（因为，例如，作为用户输入的结果，程序中某个函数中的相同参数可能会接收不同类型的数据），但我们知道所提供的数据应该具有的确切行为。

^^ 因此，接口中存储的值的实际类型在编译时是未知的。 （否则，显然，我们会在代码中指定它。）

| -> 因此，我们获得类型断言，以便能够根据我们期望程序在执行期间提供的可能值来定义程序的行为。

|-> 因此，类型断言仅适用于显式指定为接口类型的变量，而不适用于那些可能实现相同接口但未显式指定为接口类型的变量

是因为

当我们使用接口时，我们只在运行时需要这种类型断言，因为我们不知道将发送到程序的数据的确切类型 - 只有在使用接口时才需要这种类型断言，因此类型断言仅适用于显式指定为接口类型的类型，因为在所有其他情况下，数据类型都是已知的（允许编译器隐式地假定变量实现接口 - 因为它已经知道所涉及数据的所有数据类型）我们根本不需要对已知类型的数据使用类型断言。

以上就是Go 的“类型断言”方式背后的原因是什么？的详细内容，更多请关注编程网其它相关文章！