淺談Go1.18中的泛型編程
前言
經過這幾年的千呼萬喚，簡潔的Go語言終於在1.18版本迎來泛型編程。作為一門已經有瞭14年歷史的強類型語言，很難相信它到現在才開始有一個正式的泛型。
以前的Go泛型
雖然直到1.18版本才加入泛型，但是在2014年便有相關的討論要在Go中加入泛型設計。但是由於各種原因沒有實現。而之後的接口(interface)的提出，讓泛型進一步擱置。但是由於接口的缺陷，最終Go團隊還是在1.18的版本中加入瞭泛型。實際上，這一版本的泛型設計在語言層面和接口非常相似（在實現層面肯定是不一樣的，泛型是編譯時，接口是運行時），對於他們之間的差異，也會在後面提到。
本文主要講述1.18beta1版本中的泛型，後續有改動，可能會更改文章。
泛型是什麼
在我看來泛型其實用C++的模板一詞來描述就非常的準確。在寫代碼的時候，我們經常需要寫很多重復的邏輯，一般這個時候我們就會使用函數來對其進行封裝。但是由於Go是一種強類型語言，所以在定義和書寫函數的時候需要在調用前標明類型。當然如果這一重復的邏輯隻需要固定的類型，這樣就足夠瞭，但是很多時候我們需要不同的類型進行類似的邏輯，譬如我們剛剛看到的GIF。對於普通開發人員來說這種情況可能遇到的比較少，但是在一些庫開發人員來說，這種情況變得非常的普遍。
泛型程序設計（generic programming）是程序設計語言的一種風格或范式。泛型允許程序員在強類型程序設計語言中編寫代碼時使用一些以後才指定的類型，在實例化時作為參數指明這些類型。各種程序設計語言和其編譯器、運行環境對泛型的支持均不一樣。Ada、Delphi、Eiffel、Java、C#、F#、Swift 和 Visual Basic .NET 稱之為泛型（generics）；ML、Scala 和 Haskell 稱之為參數多態（parametric polymorphism）；C++ 和 D稱之為模板。具有廣泛影響的1994年版的《Design Patterns》一書稱之為參數化類型（parameterized type）。
其中，C++的模版應該是做的最完善的，不僅支持簡單的模板替換，還可以處理一些簡單的邏輯，經過不斷的迭代，已經形成瞭一種生成代碼的編程方式，因此也叫做模板元編程(Template metaprogramming)。當然由於其和C++編程方式完全不一致，所以可讀性非常的差。而在Go的泛型設計中，為瞭保證泛型的簡潔，Go並不支持模版元編程（心塞，還想試試在Go裡面往往騷操作呢）。
Go的泛型
接下來就是Go泛型的使用介紹瞭，Go支持泛型函數和泛型類型。
泛型函數
先來一個最簡單的泛型函數
func ink19FirstGen[T any](t T) {
fmt.Println(t)
}
這是一個非常簡單的的函數，就是使用fmt.Println打印輸入的參數。相比於以前的函數，多瞭[T any]部分，這就是Go泛型的參數列表。
參數列表中的參數由兩部分組成，參數名和約束，其中T就是參數，any為參數的約束。從表達上來說，和Go語言一貫的風格相似，名在前，類型在後。
在Go語言中，使用接口interface做為類型的約束，其中any = interface{}，即為無限制，但是以其說是無限制，倒不如說是完全限制，由於any裡面沒有定義任何的方法，所以在函數裡面也沒辦法調用t的任何方法。
這裡有一個非常重要的問題，就是相比較於C++的模板，Go會在定義函數的時候就對函數進行解析。所以在函數中使用瞭的方法，一定要在約束的接口中出現。
type ink19Inf interface {
Test()
}
func ink19FirstGen[T ink19Inf](t T) {
t.Test()
}
和普通參數類似的，如果是相同的約束，參數類型也支持簡化
func ink19FirstGen[T ,T2 ink19Inf](t T, t2 []T2) {
t.Test()
}
泛型類型
和C++中的模板類類似的，Go裡面也有泛型類型，它的定義也很簡單
type ink19Vector[T any] []T
結構相比與以前的類型定義多瞭[T any]部分，這一部分的結構和泛型函數那一部分類似就不多介紹瞭。
對於泛型類型，Go也可以定義相關的方法，譬如：
func (m *ink19Vector[T]) Push(v T) *ink19Vector[T] {
*m = append(*m, v)
return m
}
在泛型結構體中，結構體也可以定義自己的類型的變量，形成鏈表
type List[T1, T2 any] struct {
next *List[T1, T2]
t1 T1
t2 T2
}
PS：依據提案中的說法，第二行的參數列表應該和定義中的順序一致，以防止無限遞歸。但是在1.18beta1版本的實測中，順序不一致的寫法並不會報錯。
Go暫時不支持方法的泛型。
類型集合
雖然通過接口限制類型可以滿足絕大部分的要求，但是仍然有一些需求滿足不瞭，譬如運算符。假如我們有一個函數，可以傳入任意可比較的參數，然後返回較小的那一個。很自然的，我們可以寫下如下的代碼：
func whoismin[T any](a, b T) T {
if a < b {
return a
}
return b
}
但是，很遺憾的，由於我們對T的約束是any。所以其實來說，我們沒辦法對a和b做任何的操作，對比也是。所以在這裡，我們會收到報錯
invalid operation: cannot compare a < b (operator < not defined on T)
為瞭解決這一問題，提案中提出瞭類型集合的概念。
對於一個類型，認為它代表的類型集合就是隻包含這個類型的集合，即對於類型M來說，其代表的類型集合為{M}。而對於接口來說，其對應的類型集合是無限的，隻要一個類型滿足接口的所有方法簽名，那麼這個類型就是屬於這個接口的類型集合中。其實很容易理解類型集合就是那個識別符可以代表的類型的集合。
考慮集合的操作，對於下面這個例子
type ink19Inf1 interface {
What1()
}
type ink19Inf2 interface {
What2()
}
type ink19Inf3 interface {
What1()
What2()
}
假設ink19Inf1的類型集合為A，ink19Inf2的為B，ink19Inf3的為C。那麼很容得到C=A⋂B。即C為A和B的交集。當然隻有交集是不行的，後面還有說明實現並集。
為瞭進一步的說明類型集合，我們先來回憶一下接口的定義，對於之前的接口來說，接口的元素一共有兩種：方法簽名和其他接口。
type ink19Inf1 interface {
What()
}
type ink19Inf2 interface {
ink19Inf1
It()
}
比如ink19Inf2中的第一個元素就是其他接口，第二個元素是其他簽名。但是僅僅隻是有這兩種元素，對於泛型約束來說是完全不夠的。為此，提案中加入瞭另外三種不同的元素，需要註意的是，如果一個接口加入瞭這額外三種元素，那麼這個接口就不能再作為普通的接口使用瞭，隻能用作泛型。
第一個增加的是類型元素。以前的接口是不能用類型作為接口的，但是在作為約束中可以這樣操作。作為元素的時候就是提供瞭一個隻包含自己本身的類型作為元素的類型集合。
第二個是增加瞭近似約束元素，寫法是在類型前面增加~符號，如
type ink19Inf1 interface {
~int
}
這一個元素的意義是為接口提供瞭一個所有以int為底層類型的集合。所以被~修飾的類型也應該是一個底層類型，不然提供的集合就是空集，沒有任何意義。具體的區別可以看下面的這個例子。
type ink19Inf3 interface {
int
}
type ink19Inf4 interface {
~int
}
type MyInt int
首先我們定義瞭兩個接口，第一個接口使用的是額外的第一種元素， 因此它的類型集合隻包含瞭int。另一個使用瞭第二種元素，它的類型集合包含瞭所有以int為底層類型的類型。然後我們定義瞭一個MyInt類型，它是以int為底層類型的類型。需要註意的是，在Go中MyInt和int是兩種不同的類型。最後我們寫兩個方法來分別使用兩個接口為約束。
func ink19Print1[T ink19Inf3](t T) {
fmt.Println(t)
}
func ink19Print2[T ink19Inf4](t T) {
fmt.Println(t)
}
var data MyInt = 1
ink19Print1(data) // 錯誤
ink19Print2(data)
第三個元素是聯合約束。使用方法如下
type ink19Inf5 interface {
int | float32 | bool | ~string | ink19Inf3
}
使用方法非常簡單，就是將並集的元素一個一個使用|連接就就好瞭。需要註意的是聯合約束的元素隻支持類型，近視約束和其他隻包含以上三種額外元素的接口（即，不支持包含方法簽名的接口）。
回到之前的問題，對於需要使用操作符的情況，有瞭以上的工具後就可以解決瞭。
縱觀整個Go語言，由於並不支持操作符，所以有操作符（除瞭==和!=）的其實隻有有限的幾種類型，譬如：int，float32，string等等。
所以對於需要使用比較運算符的約束的時候，可以使用如下的一個約束接口：
type Ordered interface {
~int | ~int8 | ~int16 | ~int32 | ~int64 |
~uint | ~uint8 | ~uint16 | ~uint32 | ~uint64 | ~uintptr |
~float32 | ~float64 |
~string
}
為瞭方便使用，Go標準庫裡面提供瞭一個constraints來提供相關的約束。
上面提到，對於除瞭==和!=以外的操作符可以通過對所有的類型進行枚舉來實現。但是對於這兩個操作符，用戶自定義的類型也會有這兩個操作符，沒辦法枚舉實現。官方給出的方法是通過使用一個一個內建的約束comparable來完成操作。譬如
func IsSame[T comparable](a T, b T) bool {
return a == b
}
和接口的差異
由於本人對於Go的接口使用並不多，所以如果有不足的地方請及時指正。
- 實現方法上，泛型是編譯時，接口是運行時；
- 可以實現操作符的約束；
- 返回的參數可以是特定的類型，而接口隻能返回固定的接口類型；
- 相比較於接口，泛型的約束可以有更多的操作。
總結
以上就是Go語言泛型的使用。總的來說，比較完整，實現瞭大部分的功能，相比於接口，有一定的差異。從體驗上來說有較高的提升，但是其缺點也非常的多。首先是其後面提出的三種元素，它將接口和類型限制隔離開瞭，這是一個特別奇葩的操作，感覺不符合Go語言的簡潔實現。添加的三種元素中，我們主要來看第三種，聯合。代碼在分析的時候會對每一個元素測試，看看能不能通過編譯。所以從集合的角度上來看，如果我們把一個類型可以進行的操作可做是一個集合，那麼這一個聯合就是在一個限定的類型集合裡面（枚舉出的）對每一個類型的操作集合進行一個交集操作。回到原來，其實出現這個語法特性的最大原因就是Go語言不支持操作符重載，所以沒辦法對操作符進行枚舉，那為什麼不直接在這個版本實現操作符重載呢？或者直接不考慮這一部分，讓傳入的結構體隻能使用方法，不能使用操作符。並且，即使加入瞭這三種元素，還是有兩種操作符!=和==無法使用現在有的實現，隻能使用一個內建的符號來代表這一類的方法，個人感覺非常醜陋。
到此這篇關於淺談Go1.18中的泛型編程的文章就介紹到這瞭,更多相關Go 泛型編程內容請搜索WalkonNet以前的文章或繼續瀏覽下面的相關文章希望大傢以後多多支持WalkonNet！