why only basic data type support const declaration in golang

為什么golang的const只支持基本數(shù)據(jù)類型如int/string，而不支持復(fù)雜的數(shù)據(jù)類型

個(gè)人認(rèn)為，核心原則是，const只應(yīng)當(dāng)修飾最簡(jiǎn)單的只有一層的數(shù)據(jù)結(jié)構(gòu)。當(dāng)數(shù)據(jù)結(jié)構(gòu)存在多層引用時(shí)，如果要達(dá)到完全的const，必須遞歸地把所有被引用的底層數(shù)據(jù)結(jié)構(gòu)也進(jìn)行const。一旦數(shù)據(jù)結(jié)構(gòu)層次過多，將形成一個(gè) const hell

基本數(shù)據(jù)類型的const

// You can edit this code!
// Click here and start typing.
package main

import "fmt"

func main() {
    // c 不可變
    const c = "const_str"
    // 值傳遞賦值給a, a可變
    a := c
    fmt.Printf("a'address before modified is %p\n", &a)
    // 修改a
    a = "new_str"
    fmt.Printf("a'address after modified is %p\n", &a)

    // c is not changed, so b's value is the same as "const_str"
    b := c
    fmt.Println(a, b, c)
}

社區(qū)討論

https://github.com/golang/go/issues/6386

take a look at Slice/Map/Struct

Slice的數(shù)據(jù)結(jié)構(gòu)本身是一個(gè)結(jié)構(gòu)體，攜帶有指向底層Array的指針，len和cap

簡(jiǎn)要示例：

type slice struct {
    array unsafe.Pointer
    len   int
    cap   int
}

類似地，Map的數(shù)據(jù)結(jié)構(gòu)本身是一個(gè)結(jié)構(gòu)體，也攜帶一個(gè)指針

如果Slice/Map可以被const修飾，也就是struct可以被const修飾

questions about const slices by cznic:

// You can edit this code!
// Click here and start typing.
package main

import "fmt"

func main() {
    // if const slice is allowed, then the under struct of c is never modified
    const c = []byte{1}
    a := c
    // a and c use the same backing array, so after a changes the value at 0 position, c's value changed while under struct of c stays
    // c 的結(jié)構(gòu)體成員kv確實(shí)是不變的，但是c的成員指針指向底層array改變了，于是對(duì)于程序員來說，c并不const，或者說并沒有徹底const
    // 這樣一來，const的語意就confused了
    a[0] = 42

    b := c
    fmt.Println(b[0] == 1)  
    // The above can print 'true' only if the c's backing array is copied in assignment to 'a',
    // however the const declaration gives an illusion of always using the same backing array
}

不難發(fā)現(xiàn)，核心原則是，const只應(yīng)當(dāng)修飾最簡(jiǎn)單的只有一層的數(shù)據(jù)結(jié)構(gòu)。當(dāng)數(shù)據(jù)結(jié)構(gòu)存在多層引用時(shí)，如果要達(dá)到完全的const，必須遞歸地把所有被引用的底層數(shù)據(jù)結(jié)構(gòu)也進(jìn)行const。一旦數(shù)據(jù)結(jié)構(gòu)層次過多，將形成一個(gè) const hell

Robert Griesemer comments on this

Some comments:

1. This is neither a defect of the language nor the design. The language was
   deliberately designed to only permit constant of basic types.
2. The implications of such a change are much more far-fetching than meets the eye:
   there are numerous open questions that would have to be answered satisfactorily; and I
   don't think we are there yet.
   For instance, if we allow such constants, where is the limit? Do we allow constant maps?
   What about constant channels? Constant pointers? Is it just a special case for slices?
   etc.
   A first step might be to allow constant arrays and structs as long as they are only
   composed of fields that can have constant types themselves.
   An even smaller step (which I do think we should do) is to make "foo"[i] a constant if i
   is a constant (right now it's a non-constant byte).
   Finally, note that it's often not very hard for a compiler to detect that a
   package-level variable is never modified. Thus, an implementation may choose to optimize
   the variable initialization and possibly compute it compile time. At this point, the
   const declaration only serves as documentation and for safety; there's no performance
   loss anymore.
   But again, we have tried to keep the type system (incl. what constants are) relatively
   simple so that it doesn't get into the way. It's not clear the benefits are worth the
   price in additional complexity.

It's not clear the benefits are worth the price in additional complexity.