[[440023]]

本文轉載自微信公眾號「腦子進煎魚了」，作者陳煎魚。轉載本文請聯系腦子進煎魚了公眾號。

大家好，我是煎魚。

前面寫過好幾篇 Go 泛型的語法、案例介紹，新的一手 Go 消息。實際上，隨著一些提案被接受，新的提案也逐漸冒出。

這不，我發現有了泛型后，大家可以更進一步玩出花來了。看到了一個 ”新“ 提案《proposal: spec: generics: type switch on parametric types[1]》，講的就是增加泛型后的參數類型上的類型開關訴求。

跟著煎魚一起掌握新的 Go 知識吧!

新提案

新的提案內容是希望增加一個新的變種語句，允許在 switch 語句的類型中使用泛型時，能夠進一步便捷的約束其類型參數。

例如：

switch type T { 
case A1: 
case A2, A3: 
   ... 
} 

也就是 switch-type 語句的 T 類型可以是一個泛型的類型參數，case 所對應的的類型可以是任何類型，包括泛型的約束類型。

假設類型 T 的類型有可能是以下類型：

interface{ 
    C 
    A 
} 

可以借助泛型的近似元素來約束：

interface{ 
    C 
    A1 | A2 | ... | An 
} 

甚至還可以在 case 上有新的寫法：

case interface {~T}: 

在支持泛型后，switch 在 type 和 case 上會存在很多種可能性，需要進行具體的特性支持，這個提案就是為此出現。

實際案例

案例一：多類型元素

type Stringish interface { 
 string | fmt.Stringer 
} 
 
func Concat[S Stringish](x []S "S Stringish") string { 
    switch type S { 
    case string: 
        ... 
    case fmt.Stringer: 
        ... 
    } 
 } 

類型 S 能夠支持 string 和 fmt.Stringer 類型，case 配套對應實現。

案例二：近似元素

type Constraint interface { 
    ~int | ~int8 | ~string 
} 
 
func ThisSyntax[T Constraint]( "T Constraint") { 
    switch type T { 
    case ~int | ~int8: 
        ... 
    case ~string: 
        ... 
    } 
} 
 
func IsClearerThanThisSyntax[T Constraint]( "T Constraint") { 
    switch type T { 
    case interface{~int | ~int8 }: 
        ... 
    case interface{ ~string }: 
        ... 
    } 
} 

類型 T 可能有很多類型，程序中用到了近似元素，也就是基礎類型是 int、int8、string，這些類型中的任何一種都能夠滿足這個約束。

為此，switch-type 支持了，case 也要配套支持該特性。

爭議點

看到這里可能大家也想到了，這個味道很似曾相識，好像某個語法能夠支持。因此，這個提案下最有爭議的，就是與原有的類型斷言的重復。

原有的類型斷言如下：

switch T.(type) { 
case string: 
   ... 
default: 
   ... 
} 

新的類型判別如下：

switch type T { 
case A1: 
case A2, A3: 
   ... 
} 

這么咋一看，其實類型斷言的完全可以取代新的，那豈不是重復建設，造輪子了?

其實是沒有完全取代的。差異點如下：

type ApproxString interface { ~string } 
 
func F[T ApproxString](v T "T ApproxString") { 
    switch (interface{})(v).(type) { 
    case string: 
        fmt.Println(v) 
    default: 
        panic("腦子沒進煎魚") 
    } 
} 
 
type MyString string 
 
func main() { 
    F(MyString("腦子進煎魚了"))  
} 

看出來差別在哪了嗎，答案是什么?

答案是：會拋出恐慌(panic)。

你可能糾結了，問題出在哪里?這傳入的 ”腦子進煎魚了“ 的類型是 MyString，他的基礎類型是 string 類型，也滿足 ApproxString 類型的近似類型 ~string 的要求，怎么就不行了...

根本原因是因為他的類型是 interface，而非 string 類型。所以走到了 defalut 分支的恐慌。

總結

今天給大家介紹了 Go 泛型的最新消息，在上一個提案被合并后，該提案也有一些新的動靜，不過 Go 官方表態，會等熟練掌握泛型實踐后，再繼續推動該提案。

我相信原有的 switch.(type) 和 switch type 很大概率在 Go 底層會變成同一個邏輯塊處理，再逐漸過渡。

這個提案的目的還是為了解決若干引入泛型后，所帶入的 BUG/需求，正正是需要新的語法結構來解決的。

你對此有什么看法呢，歡迎在評論區留言和交流：)

參考資料

[1]proposal: spec: generics: type switch on parametric types: https://github.com/golang/go/issues/45380