Go 使用動態和靜態綁定。根據我的理解，如果您需要使用類型斷言，那么它是動態的。我想驗證我的假設。type Xer interface { X()}type XYer interface { Xer Y()}type Foo struct{}func (Foo) X() { println("Foo#X()") }func (Foo) Y() { println("Foo#Y()") }假設：foo := Foo{}// static: Foo -> XYervar xy XYer = foo// static: XYer -> Xervar x Xer = xy// static: Xer -> interface{}var empty interface{} = x// dynamic: interface{} -> XYerxy2 := empty.(XYer)// dynamic: XYer -> Foofoo2 := xy2.(Foo)因此，當從type A->轉換時interface B，如果A滿足B則不需要斷言，并且可以在編譯時生成 itable。如果您在不需要斷言的情況下使用斷言呢？var x Xer = Foo{}empty := x.(interface{})在這種情況下會發生什么？如果有人可以為我澄清這一點，那就太好了。
2 回答
明月笑刀無情
TA貢獻1828條經驗 獲得超4個贊
我不知道什么是接口的靜態綁定或接口的動態綁定。語言規范從未提及此類術語。讓我假設您的意思是在編譯時進行類型檢查，在運行時進行類型檢查。有了這個假設，你所有的例子都是，AFAICS，正確的。它歸結為一個簡單的模式（相關語言規范部分的精簡版本）：
所有賦值都在編譯時進行類型檢查。
所有類型斷言 (
.(T)) 在運行時都經過類型檢查。
這也回答了“在這種情況下會發生什么？” .
也就是說，編譯器可以自由地優化可以在編譯時證明類型已知且賦值兼容的情況。但這只是一個不能依賴的實現細節 - 因為其他符合規范的實現可能不是這種情況。
實際上 gc 編譯器有 (IINM) 這樣的優化，甚至在相反的意義上。它可以說“不可能的類型斷言”，它可以在編譯時證明類型斷言將失敗。
- 2 回答
- 0 關注
- 207 瀏覽
添加回答
舉報
0/150
提交
取消