go 中的范型

TimLiuDream · 2023-03-16 22:23:16 · 3165 次点击 · 大约8小时之前 开始浏览    置顶
这是一个创建于 2023-03-16 22:23:16 的主题,其中的信息可能已经有所发展或是发生改变。

泛型是随着Go 1.18版本发布的。它基本上意味着参数化的类型,也就是说,它允许程序员在写代码时,类型可以稍后指定,因为类型在当时并不相关。换句话说,在编写一些代码时,你不提供数值的类型。这些类型的值会在以后传递。

其语法为:

func funcName[type_parameter type_constraint](… type_parameter) type_parameter {
 …
}

func funcName[T any](… T) T {
 …
}

func funcName[T interface{}](… T) T {
 …
}

这里T是类型参数,any是类型约束,可以是任何接口,意味着无限的值,这里any代表一个空接口。

在下面的例子中,有两个函数,第一个returnFirst接受 any,意味着我们可以传递任何非特定的int或float,并且它返回第一个参数。第二个函数即returnFloatFirst只接受float64类型的参数,如果我们传递任何其他类型的参数,它就会抛出一个错误。在main函数中,你可以看到我们可以在不指定约束类型的情况下调用returnFirst函数,并且它是有效的,这是因为类型推理。

func returnFirst[T any](a T, b T) T {
  return a 
}

func returnFloatFirst[T float64](a T, b T) T {
  return a 
}

func main() {
  fmt.Println(returnFirst[int](1,3))
  fmt.Println(returnFirst(1,3))
  fmt.Println(returnFirst[float64](1.8,3.9))
  fmt.Println(returnFirst(1.8,3.9))
  fmt.Println(returnFirst("a","b"))
  fmt.Println(returnFloatFirst(1.2,3.4))
}

Go 1.18带有类型推理功能,可以帮助我们编写无需显式类型就能调用通用函数的代码。

让我们再举一个例子,比如说你要计算数组中所有元素的总和,现在如果我说每次改变数组存储的数据类型,那么函数的实现将保持不变,但你必须写一个单独的函数来适应不同的类型,所以让我们写一个通用函数,将数组中的元素相加并返回总和。

func sumAll[T any](arr []T) T {
  var s T
  for _, ele := range arr {
    s += ele
  }
  return s
}

func main() {
  fmt.Println("sum: ", sumAll([]int{1, 2, 3, 5, 6}))
}

当你运行上述代码时,会出现一个错误:

$ go run main.go
./main.go:6:9: invalid operation: operator + not defined on a (variable of type T constrained by any)

这是因为任何约束都可以持有任何值,在上面的例子中,它是int,但它可以是任何东西,而且有可能运算符对那个特定的类型不起作用,所以它抛出一个错误。为了解决这个问题,我们使用类型集,在接口的帮助下定义一个自定义约束,并在类型约束的地方使用它。我们为该约束声明一组类型,我们必须只使用这些类型。

定义自定义约束的语法是:

type customConstraint interface {
  type1 | type2 | type3 …
} 

type cusConstraint interface {
  float64 | int | string
}

我们还可以使用约束包,它定义了一组有用的约束,可以与参数一起使用。

首先,我们必须安装约束包。

$ go get golang.org/x/exp/constraints

来自包的一些限制。

type Signed interface {
  ~int | ~int8 | ~int16 | ~int32 | ~int64
}

type Unsigned interface {
  ~uint | ~uint8 | ~uint16 | ~uint32 | ~uint64 | ~uintptr
}

type Integer interface {
  Signed | Unsigned
}

type Float interface {
  ~float32 | ~float64
}

type Complex interface {
  ~complex64 | ~complex128
}

type Ordered interface {
  Integer | Float | ~string
}

所以现在让我们创建一个自定义约束,它可以支持float64和int类型的数据,并在任何约束的位置使用它。

type constraint interface {
  ~float64 | int
}

func sumAll[T constraint](arr []T) T {
  var s T
  for _, ele := range arr {
    s += ele
  }
  return s
}

func main() {
  fmt.Println("sum: ", sumAll([]int{1, 2, 3, 5, 6}))
  fmt.Println("sum: ", sumAll([]float64{1.2, 2.1, 3.8, 5.4}))
}

上述代码是有效的。

感兴趣的可关注:

截屏2023-03-12 23.15.28.png


有疑问加站长微信联系(非本文作者)

入群交流(和以上内容无关):加入Go大咖交流群,或添加微信:liuxiaoyan-s 备注:入群;或加QQ群:692541889

3165 次点击  ∙  2 赞  
加入收藏 微博
14 回复  |  直到 2023-03-23 17:02:19
lysShub
lysShub · #1 · 2年之前

泛型加any,相当于是集糟粕于一身

zzustu
zzustu · #2 · 2年之前
lysShublysShub #1 回复

泛型加any,相当于是集糟粕于一身

相当于既没把 any 放在合适的位置上,又没把 泛型 放在合适的位置上

symphony09
symphony09 · #3 · 2年之前
lysShublysShub #1 回复

泛型加any,相当于是集糟粕于一身

没有质疑的意思,可以具体说说是什么糟粕吗,谢谢

lysShub
lysShub · #4 · 2年之前
symphony09symphony09 #3 回复

#1楼 @lysShub 没有质疑的意思,可以具体说说是什么糟粕吗,谢谢

这样的泛型没有实际意义,最终还是会对any断言。而且泛型接口还有性能问题 https://www.infoq.cn/article/xprmcl5qbf6yvdroajyn

Neightly
Neightly · #5 · 2年之前
lysShublysShub #4 回复

#3楼 @symphony09 这样的泛型没有实际意义,最终还是会对any断言。而且泛型接口还有性能问题 https://www.infoq.cn/article/xprmcl5qbf6yvdroajyn

马上都21了,还拿18的老黄历说事合适吗?还是觉得Go Team一年多时间已经放弃治疗了?

symphony09
symphony09 · #6 · 2年之前
lysShublysShub #4 回复

#3楼 @symphony09 这样的泛型没有实际意义,最终还是会对any断言。而且泛型接口还有性能问题 https://www.infoq.cn/article/xprmcl5qbf6yvdroajyn

谢谢回复,关于第一点我觉得还可以再讨论下。举例来说,泛型队列只关心元素间次序关系,不关心元素的结构和功能。这时使用 any 约束应该是恰当的,并且也不涉及断言,因为不需要使用元素的特定功能。

symphony09
symphony09 · #7 · 2年之前
NeightlyNeightly #5 回复

#4楼 @lysShub 马上都21了,还拿18的老黄历说事合适吗?还是觉得Go Team一年多时间已经放弃治疗了?

大家友善交流哈,我是觉得说一下也不是坏事,能让人留点心。如果 Go Team 确实做了优化,还能水篇文章哈哈。

lysShub
lysShub · #8 · 2年之前
symphony09symphony09 #6 回复

#4楼 @lysShub 谢谢回复,关于第一点我觉得还可以再讨论下。举例来说,泛型队列只关心元素间次序关系,不关心元素的结构和功能。这时使用 any 约束应该是恰当的,并且也不涉及断言,因为不需要使用元素的特定功能。

你那限制条件多严格?这种函数基本不存在、没有现实一样

lysShub
lysShub · #9 · 2年之前
NeightlyNeightly #5 回复

#4楼 @lysShub 马上都21了,还拿18的老黄历说事合适吗?还是觉得Go Team一年多时间已经放弃治疗了?

怎么就老黄历了?哪些是过时的了?最近几版的changelog你看了?

Neightly
Neightly · #10 · 2年之前
lysShublysShub #9 回复

#5楼 @Neightly 怎么就老黄历了?哪些是过时的了?最近几版的changelog你看了?

真不好意思都看过,和泛型相关的几个proposal也都看过。 不会像那些连underlying type、core type、comparable都没弄清楚的人一样,先怼为敬。先是嫌弃[]没有<>好看,然后就是嫌弃这个限制那个限制啥都想要。 当年Java5为了兼容性搞了个类型擦除也没几个跳脚的。C++模版导致大量重复编译也没见几个跳脚的。 单单就是看不惯Go在其中做出的tradeoff,好像不吐槽几句就亏了一样。

symphony09
symphony09 · #11 · 2年之前
lysShublysShub #8 回复

#6楼 @symphony09 你那限制条件多严格?这种函数基本不存在、没有现实一样

准备在1.21版本加入标准库的泛型map实现,就多处用到了 any 约束,不能说不存在吧。详见:https://github.com/golang/go/issues/57436

lysShub
lysShub · #12 · 2年之前
NeightlyNeightly #10 回复

#9楼 @lysShub 真不好意思都看过,和泛型相关的几个proposal也都看过。 不会像那些连underlying type、core type、comparable都没弄清楚的人一样,先怼为敬。先是嫌弃[]没有<>好看,然后就是嫌弃这个限制那个限制啥都想要。 当年Java5为了兼容性搞了个类型擦除也没几个跳脚的。C++模版导致大量重复编译也没见几个跳脚的。 单单就是看不惯Go在其中做出的tradeoff,好像不吐槽几句就亏了一样。

所以接口泛型是没有性能损失了,还是不需要断言了?

Neightly
Neightly · #13 · 2年之前
lysShublysShub #12 回复

#10楼 @Neightly 所以接口泛型是没有性能损失了,还是不需要断言了?

杠精。什么叫损失?和什么比的损失?你要说损失是吧,抽象有没有损失?复制一堆函数叫不叫损失?代码膨胀叫不叫损失?为了兼容多平台编译了本不需要的代码叫不叫损失?

Neightly
Neightly · #14 · 2年之前
lysShublysShub #12 回复

#10楼 @Neightly 所以接口泛型是没有性能损失了,还是不需要断言了?

要说损失是吧,reflect提鞋都不配。谁用得少还是怎么的?

添加一条新回复 (您需要 登录 后才能回复 没有账号 ?)
  • 请尽量让自己的回复能够对别人有帮助
  • 支持 Markdown 格式, **粗体**、~~删除线~~、`单行代码`
  • 支持 @ 本站用户;支持表情(输入 : 提示),见 Emoji cheat sheet
  • 图片支持拖拽、截图粘贴等方式上传