Go 的謎團：結構體賦值中缺乏類型推斷
在Go 中，使用簡寫聲明語法賦值是一種常見的做法賦值提高程式碼的可讀性和效率。然而，這種簡單性可能會讓程式設計師在遇到某些場景時陷入困境，如以下程式碼片段所示：
i := 10 next := 11 prev, i := i, next
此程式碼片段將next 的值分配給i，同時將i 重新分配給prev。這種行為很直觀並且按預期工作。但是，當涉及結構體欄位時，類型推斷會失敗，如下列程式碼所示：
type Foo struct {
Bar int
}
f := Foo{10}
next := 11
prev, f.Bar := f.Bar, next在這種情況下，嘗試使用簡寫語法將值指派給結構體欄位會導致編譯器錯誤：「non-name on left side of :=」
引人注目的是，此錯誤僅在處理結構時發生。為了解開這種行為背後的謎團，我們深入研究 Go 編譯器複雜的型別推斷機制。
當編譯器遇到簡寫聲明時，它會嘗試根據右側的表達式來推斷類型 -作業的手邊。對於變量，這個過程很簡單。但是，當遇到結構體欄位時，編譯器會檢查該欄位的類型與右側表達式的類型是否相符。
在第一個範例中，右邊是整數文字(11) 與 i 的型別相符。因此，編譯器可以推論 prev 也是一個整數，並且賦值成功。
在第二個範例中，右側是涉及結構體欄位 (f.Bar) 的表達式。由於編譯器需要確保左側的類型（本例中為 f.Bar）與右側的類型匹配，因此會陷入衝突：右側是整數，但左側是一個 int 類型的結構體欄位。這種差異導致編譯器無法推斷 prev 的類型，從而出現錯誤。
這種情況的令人困惑的方面是，雖然錯誤訊息指示「non-name on left side of :=」作為罪魁禍首，根本問題似乎在於由於結構體字段的參與而導致類型推斷失敗。
此行為已被報告為未解決的問題Go 問題追蹤器，強調 Go 處理結構時類型推斷的局限性。雖然它在技術上可能不屬於錯誤，但它確實代表了編譯器的剛性阻礙了直觀的編碼實踐的領域。
以上是為什麼 Go 的型別推論在使用簡寫聲明的結構體賦值中失敗？的詳細內容。更多資訊請關注PHP中文網其他相關文章！
