相信大家在接觸 Go 這門編程語言時，就會學到常量這個知識點。

各大編程語言會教你，常量是不可變變量的一種類型。只要定義了常量，你就可以安心的用他。不用擔心值在哪里就被程序莫名奇妙的給改了。

常量的使用例子

如下例子：

const s string = "腦子進煎魚了"
func main() {
    fmt.Println(s)
    const n = 500000000
    const d = 3e20 / n
    fmt.Println(d)
    fmt.Println(int64(d))
    fmt.Println(math.Sin(n))
}

輸出結果：

腦子進煎魚了
6e+11
600000000000
-0.28470407323754404

你可能會發(fā)現(xiàn)一個奇怪的點。那就是例子里都是基本的數(shù)據(jù)類型。那能不能用復雜點的數(shù)據(jù)類型呢，例如 Go 里比較經(jīng)典的切片。

如果是用 var 聲明：

var s = []string{"摸", "煎", "魚"}
func main() {
    fmt.Println(s)
}

正常輸出：[摸 煎 魚]

如果是用 const 聲明：

const s = []string{"摸", "煎", "魚"}

將會報錯：

./prog.go:7:11: []string{…} (value of type []string) is not constant

因為在 Go 中，僅支持字符、字符串、布爾和數(shù)值類型的常量。這和其他編程語言間多多少少還是有點不一樣的。

為什么不支持更多類型

為什么在 Go 中常量只支持這幾種基礎類型，為什么沒法支持復雜類型，甚至是所有類型？

這是非常奇怪的。畢竟 PHP 都能支持：

class MyClass
{
    const ABC = array('A', 'B', 'C');
    const A = '1';
    const B = '2';
    const C = '3';
    const NUMBERS = array(
        self::A,
        self::B,
        self::C,
    );
}

這又是出于什么緣由？

已有 10 年老提案

我認真翻閱了 Go issues 等相關資料，終于發(fā)現(xiàn)竟然在 2013 年（10 年前），就已經(jīng)有人提出過這個提案：

提出者 @RickySeltzer，認為：

var each1 = []byte{'e', 'a', 'c', 'h'}

可以正常運行。

const each2 = []byte{'e', 'a', 'c', 'h'}

不行，直接報錯：prog.go:7: const initializer []byte literal is not a constant。

他認為這就是 Go 語言規(guī)范和設計上的缺陷，得改，得支持！

拒絕的論據(jù)是什么

對此也有各種爭論，老大哥 @Robert Griesemer，10 年前已

在為 Go 貢獻，現(xiàn)在依然還在...他對 Go 常量只支持基本類型這個設計給出了定論。

基于如下原因：

首先這不是語言的缺陷，也不是設計的缺陷。Go 語言的常量是故意設計成只支持基本類型。

基本類型到復雜類型的改變，這種變化的影響比我們看到的要深遠得多。需要考慮很多問題。

• 常量 channel、常量指針、常量 maps、常量 slice 都要支持嗎？
• 先支持常量 array 和 常量 struct？
• 要支持到什么程度，以什么來作為標準決定？

設計上，Go 團隊期望類型系統(tǒng)（包括常量的含義）相對簡單，以免在編譯時出現(xiàn)問題。

• 常量更多類型的支持，會增加復雜性。不清楚這樣做的好處是否值得（ROI）。
• 常量是否可以尋址？const 數(shù)組的元素本身必須是 const 嗎？

匯總一下，潛臺詞就是：

• 設計如下：常量只支持基本類型，是 Go 設計上就是這么決定的。
• ROI 要衡量一下：沒有支持更多的復雜類型，是認為好處不多。也沒有想清楚這塊的緣由。
• 少即是多：類型系統(tǒng)要保持少即是多（less is more）。

實戰(zhàn)中的騷操作

在相關提案的 issues 中看到歐神（@Changkun Ou）也參與了討論，他例舉了一個常量的經(jīng)典騷操作。

代碼如下：

- const ErrVerification = errors.New("crypto/rsa: verification error")
+ var ErrVerification = errors.New("crypto/rsa: verification error")

在對應的 Go 工程中可能是這么使用：

import "cropto/rsa"
func init() {
 rsa.ErrVerification = nil
}

這個場景我還真見過，一開始想定義 const，結果不支持。只能被迫 var。這不，就開天窗了。

總結

Go 核心團隊在綜合衡量 ROI 后，認為常量支持更多的類型在可預見的未來不會改變。因為將常量的概念擴展到基本類型之外將是一個重大變化，會產(chǎn)生各種影響。

在此刻（Go1）改變語言的門檻非常高，需要有明確的定義，要有完整的提案以及對成本和效益等的詳細分析。

如果出現(xiàn)，只可能在未來的 Go2。但結合 rsc 最新的結論，沒有 Go2 的話，那如果未來真的做，那就是通過 GODEBUG 和 go.mod 的 go 版本號來實現(xiàn)了。

常量更多類型的支持，雖然已經(jīng)提出了 10 年。但目前 Go 核心團隊推進乏力，想必，可能還要個 5 年吧。

以上就是淺析Go常量為什么只支持基本數(shù)據(jù)類型的詳細內(nèi)容，更多關于Go常量的資料請關注腳本之家其它相關文章！

最新評論