关于golang:新提案Go-泛型玩出花来了switch-type-登场

大家好，我是煎鱼。

后面写过好几篇 Go 泛型的语法、案例介绍，新的一手 Go 音讯。实际上，随着一些提案被承受，新的提案也逐步冒出。

这不，我发现有了泛型后，大家能够更进一步玩出花来了。看到了一个”新“提案《proposal: spec: generics: type switch on parametric types》，讲的就是减少泛型后的参数类型上的类型开关诉求。

跟着煎鱼一起把握新的 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/ 需要，正正是须要新的语法结构来解决的。

你对此有什么认识呢，欢送在评论区留言和交换：）

若有任何疑难欢送评论区反馈和交换，最好的关系是相互成就 ，各位的点赞就是煎鱼创作的最大能源，感激反对。

文章继续更新，能够微信搜【脑子进煎鱼了】浏览，本文 GitHub github.com/eddycjy/blog 已收录，学习 Go 语言能够看 Go 学习地图和路线，欢送 Star 催更。

关于golang:新提案Go-泛型玩出花来了switch-type-登场

新提案

理论案例

案例一：多类型元素

案例二：近似元素

争议点

总结