Go 的演進：泛型方法的提案

多年來，Go 社群一直在應對語言型別系統中一個奇特的限制：雖然函式和型別可以是泛型的，但方法（methods）卻不行。如果你想要一個方法來處理多種型別，你被迫將該邏輯移至獨立的泛型函式中，這往往導致 API 設計笨拙且套件結構「不協調」。

現在，一項新提案建議針對 Go 如何處理方法進行「觀點轉變」。透過將具體方法（concrete methods）與其作為介面實作者的角色解耦，Go 團隊正提議終於為語言引入泛型方法。

核心問題：方法 vs. 介面

要理解為什麼最初的泛型實作中省略了泛型方法，必須先理解 Go 中具體方法與介面之間的關係。從歷史上看，方法的主要目的是為了滿足介面。

如果 Go 允許具體方法擁有型別參數（例如 func (s *S) DoSomething[T any](val T)），邏輯上也會推導出介面也應該允許它們。然而，實作泛型介面方法是一個重大的技術挑戰。因為 Go 使用結構化型別（structural typing，即型別隱含地實作介面），編譯器無法在編譯時得知透過介面在執行時可能呼叫的泛型方法的所有可能實例化情況。

長期以來，官方立場——如 Go FAQ 所反映的——是，由於這個介面瓶頸，語言可能永遠不會加入泛型方法。

「觀點轉變」

新提案主張，無論是否實作介面，具體方法本身就是有用的。方法提供了：

  1. 更好的組織性： 它們將邏輯直接與其操作的數據關聯起來。
  2. 語法流暢性： 它們可以實現方法鏈結（x.a().b().c()），這比巢狀函式呼叫（c(b(a(x)))）更具可讀性。

該提案建議一個務實的折衷方案：允許泛型具體方法，但不允許它們用來滿足介面。

在此規則下，如果一個介面定義了方法 m(string)，一個具體方法 m[P any](P) 並不符合它，因為介面方法不能擁有型別參數。這讓 Go 團隊能夠提供泛型方法的語法和組織優勢，而無需解決極其複雜的泛型介面分派問題。

技術實作與語法

提議的變更在語法上是極小的。方法宣告將會更新以反映函式宣告：

MethodDecl = "func" Receiver MethodName [ TypeParameters ] Signature [ FunctionBody ]

實際範例

基礎泛型方法：

type S struct { ... }
func (*S) m[P any](x P) { ... }

var s S
s.m[int](42) // Explicit type argument
s.m(x)       // Type inference

帶有泛型方法的泛型接收者：

type G[P any] struct{ ... }
func (*G[P]) m[Q any](x Q) { ... }

編譯器影響

該提案指出，透過非介面接收者呼叫方法可以靜態地在編譯時解析。從概念上講，編譯器可以將這些呼叫重寫為泛型函式呼叫，從而使實作變得可行，且不會引入顯著的執行時開銷。

社群反應：意見分歧

這項公告引起了 Go 社群的一系列反應，反映了追求表達能力與重視 Go 原本極度簡約哲學的人之間更廣泛的緊張關係。

熱衷者

許多開發者感到寬慰，因為這填補了從其他現代語言轉過來的開發者所面臨的關鍵缺口。一位使用者指出，這將消除對「奇怪且笨拙的套件 API」的需求，而其他人則對終於能夠實作像 monads 這樣的複雜模式表示興奮。

傳統主義者

相反地，有些人認為這是對 Go 核心身分的背離。批評者認為，追逐使用者期望會導致「功能蔓延」（feature creep），且加入這種複雜度標誌著語言簡約性的下降。

"A sad day for Go, the pHDs have won, simplicity has died."

結論

透過引入泛型具體方法，Go 正在嘗試彌合理論純粹性與開發者生產力之間的差距。雖然它沒有解決泛型介面的問題，但它它承認了方法作為組織代碼的一種方式的實用性，往往超過了每個方法都必須是介面實作者的必要性。如果被採納，這項變更很可能會引發一波套件重構浪潮，因為開發者會將泛型邏輯從套件層級的函式移回它們所屬的型別中。

Sources