Go constants only support primitive data types? Why? The community has been torn for 9 years...

Hello everyone, I am fried fish.

A proposal shared with you today has been discussed in the Go community for a full 9 years (2013~2022), and it is closely related to our daily programming.

Today, let Jianyu study and understand the proposal " proposal: spec: allow constants of arbitrary data structure type " together with you, and see if there are any new ideas.

background

Let's first look at the following sample code, as follows:

 package main

import "fmt"

func main() {
    var each1 = []byte{'e', 'd', 'd', 'y'}
    const each2 = []byte{'e', 'd', 'd', 'y'}
    fmt.Printf("each1 is %q\n", each1)
    fmt.Printf("each2 is %q\n", each2)
}

What is the result of the operation, is it normal output, or is it?

The final running result is as follows:

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

The result is that the Go compilation fails and the compilation fails.

The reason is that there is an error in the constant definition in line 7 (that is, the line with the const keyword). The value of type []byte cannot be declared and defined as a constant.

It's also foggy after I understand it. Go's constant definitions have type restrictions. Why?

expect

Combining with another proposal " proposal: Go 2: add const literals for reference types like structs, maps, and arrays ", it points to similar demands.

The purpose is to be able to declare something like:

 const keys = [...]string{"煎鱼", "eddycjy", ... }

It is expected that Go will allow the definition of other types of constants, such as: structure (struct), dictionary (map) and array (array), etc., will no longer generate compilation errors and run smoothly.

After accepting the proposal, the author of the proposal believes that it can be implemented without affecting the original Go code, there will be no destructive upgrade, and the code can be effectively simplified.

What do you think, is there anything more to expect?

Reason not supported

@Robert Griesemer of the Go core team said: Constants are intentionally designed to only support primitive types (conceived from day 1 of Go), not a language flaw, not a design flaw, and think the implications of opening them up farther than expected.

I don't know to what extent the value type support of constants should be opened to channel, slice, and pointer types? So under uncertainty, not knowing how much complexity there is, officials try to keep the type system (including what the constants are) relatively simple.

At the same time, there is no obvious benefit in doing this at this stage. If it were to be changed, it would only be possible for some new adjustments to take place in Go2, not Go1.

real scene

In the comment area, I saw Ou Shen (@Changkun Ou) leave a message, citing the classic usage scenario of "constant error".

code show as below:

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

If the following code appears in one of the project dependencies, it will break the whole system:

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

This is very common in the project code. The earliest internal package wants to define the constant error of const, and finally it can only be forced to operate on the var stream.

In these scenarios, you are not sure where your values have been changed, and you have to check for a long time. The root cause is that Go's immutable variables are partially missing.

Summarize

In today's article, we introduced the most common constant (const) in Go, which in fact only supports the definition of primitive types. In view of its shortcomings, we combined the discussions and usage scenarios in the proposal to illustrate.

In contrast, Go official is very cautious about the type support of this constant, and believes that the benefits are unclear and the complexity may increase, and it is better to think that it is simple.

What do you think? Welcome to leave a message and discuss in the comment area.

The article is continuously updated, you can read it on WeChat by searching [Brain Fried Fish]. This article has been included in GitHub github.com/eddycjy/blog . To learn Go language, you can see the Go learning map and route . Welcome to Star to urge you to update.

Go Book Series

• Introduction to the Go language series: a preliminary exploration of the actual combat of the Go project
• Go Programming Journey: Deep Dive into Go Projects
• Go Language Design Philosophy: Understanding Go Why and Design Thinking
• Go Language Advanced Tour: Go deeper into the Go source code

read more

• Go wants to add an arrow syntax, which is more like PHP!
• New ideas for error handling in Go? Use left-hand functions and expressions