Go语言的“类型Assert”背后的原因是什么?

qltillow  于 2023-04-09  发布在  Go
关注(0)|答案(2)|浏览(170)

我试图让我的头脑围绕这样一个事实,即Golang的类型Assert只适用于显式定义为接口类型的变量,而不适用于具体类型(即“string”,“int 32”等)。
下面是一个快速而简单的代码示例,它说明了我困惑的根本原因:

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)
}

正如这个问题的标题所暗示的,我无法理解实现类型Assert只对接口类型起作用的背后的推理,并检查分配给实现该接口的变量的底层值是否是我们在“”中指定的。(T)”Assert方法。这让我觉得“类型Assert”是一个无意的用词不当,暗示它适用于所有类型,但不是,仅适用于接口类型。
我的意思是,这个语言设计决策背后显然一定有一个原因,我认为这可能与惯用Golang的编写方式有关,但是尽管我已经看到了很多关于这个问题的资源,他们从来没有指定这个原因。
对我来说有意义的原因是,如果Go程序应该,“最好(我假设,因为显式接口定义是可选的)”,用所有表示某个接口(行为)的变量来编写,因此为了清晰和可读性的目的,在变量上定义显式接口是有意义的。
但正如我所提到的,我从来没有看到任何资源指定为什么这是Go中“类型Assert”功能的实现方式,我希望你能帮助我澄清这个困惑。

  • -- upd 1* -添加一点来澄清我的问题:

在它的核心,我想,我的问题是关于为什么(我不明白)类型Assert只在变量的接口被显式实现时有效,而不是在接口被隐式实现时。
正如“whateverFunction”所展示的,代码确实考虑“newRect”来实现“Shape”接口,或者“成为“Shape”接口的实现”(否则函数将无法使用该变量,但它确实如此),但类型Assert“.(T)”方法后面的代码考虑“newRect”作为“Shape”接口的实现。
因此,如果Golang在考虑接口实现方面存在差异,我认为这样的设计决策背后一定有原因(差异化)。
这就是为什么我提到到目前为止我能想到的唯一原因是,如果这是一种让人们以某种方式编写Go代码的方法。

pepwfjgg

pepwfjgg1#

类型Assert检查接口中包含的值的类型。这就是它的定义方式:
https://go.dev/ref/spec#Type_assertions
这是因为接口包含两个值:值的类型和实际值,以及检查包含在接口中的值是否具有特定类型是运行时操作。
未为非接口值定义类型Assert,因为此类值的类型已经已知,并且不能是其他类型。
你可以使用type-assertion来检查一个接口是否实现了另一个接口。这意味着,接口中包含的具体值也实现了类型Assert的接口。
现在,回到你正在尝试做的事情:

v, ok := newRect.(Shape)

这很简单:

v:=Shape(newRect)

因为如果newRect没有实现Shape接口,这个表达式就是编译时错误,而不是运行时检测类型Assert。

irlmq6kh

irlmq6kh2#

你可以看看Burak Serdar's的答案-你可能会发现它更简洁和有帮助。尽管如此,我将发布整个推理链,使它最终为我 * 点击 *:
|当我们不能确定我们期望接收的数据的确切类型时(因为,例如,作为用户输入的结果,程序中某个函数中的相同参数可能接收不同类型的数据),但我们知道所提供的数据应该具有的确切行为时,使用接口。
^^因此,存储在接口中的值的实际类型在编译时是未知的(否则,显然,我们会在代码中直接指定它)。
| - 〉因此,我们被赋予类型Assert,以便能够基于我们期望程序在执行期间提供的可能值来定义程序的行为。
|- 〉因此,类型Assert只对显式指定为接口类型的变量起作用,而不对那些可能实现相同接口但未显式指定为接口类型的变量起作用的原因是

  • 是因为 *

我们只在运行时需要这样的类型Assert,当我们使用接口时,因为我们不知道将被发送到程序的数据的确切类型-这是只有在使用接口时才出现的必要性,因此类型Assert只适用于明确指定为接口类型的类型,因为在所有其他情况下数据的类型是已知的(允许编译器隐式地假设通过变量实现接口-因为它已经知道所涉及的数据的所有数据类型),并且我们根本不需要对类型已知的数据使用类型Assert。

相关问题