proposal: add const types (Go2)

[ghasemloo]

Summary:
I propose adding const types. E.g.

var x const[]string

Background:
Often when passing a value to a function one wants to make sure that the object passed will not be modified. However there is no way to grantee that, even if the function is not modifying the passed value at the moment there is no grantee someone in future might change a part of the function. This gets worse when the value has to be passed from the function to other functions as one now has to make sure that they won't be changing the value as well. This has caused several bugs in our code where object that was passed to a function got modified.

One can make a copy before calling the function, however when a struct is a large one like a large protobuf it can negatively effects the performance. One cannot assume that the function will not change the value since the developer of the function might change it in future, so for safety one would need to pass a copy.

Also making a copy of a complex object is not easy either right now because of lack of a DeepCopy function, one has to be familiar with the structure of the type and anything inside it and if any of them changes in future it will cause bugs.

Proposal:
Add const types to language. It adds complexity to the type system of Go, but the additional complexity is not a big one and const types are something developers are generally familiar with it.

Impact:
No impact on existing code.

Discussion:
This can simplify code and make sure the code is efficient and while safe in the long run. I am sure there has been discussions about adding const types to the language and probably has been avoided to keep the type system of the language simple. But this issue keeps leading to bugs in code and it is hard to stop. The fact that a value passed to a function or over a chan will not be modified should be explicit in the language.

Alternatives:

Alternative 1: explicit copy before passing values
Negatively effects performance for large types like nested protobufs. In addition it is not safe since there is no DeepCopy function.

Alternative 2: do not copy, add a comment to the function that the value will not be modified
First, from the brevity perspective, adding a comment to a function to say parameters x, y, z will not be modified is more verbose than just adding const to their type.

But more importantly, in my experience, it simply does not work and leads to difficult to find bugs. Developers change functions and comments, forget to add such comments. With nested function calls it becomes really difficult to maintain the contract that the value will not be modified. One has to check the comments of each function when passing value to other functions which it promised will not modify.

Practically impossible when passing values to chans or functions variables that the developer might not be able to figure out easily where they come from and there are no comments to check if the chan or function will modify the passed value or not.

[kevinburke]

This is a duplicate of #21130, I think, the text looks identical.

[ghasemloo]

@kevinburke
It is not duplicate, that one is about const literals for structs, arrays, and maps, ... this one is about const types, they are very different things. Please reverse marking this as duplicate.

[dominikh]

Reopening.

[ianlancetaylor]

This proposal needs much more explanation to have a chance of being adopted. The example is about a variable, but the text is about passing an argument to a function. When is const permitted? What are the rules about assignments from a value of type []byte to a value of type const []byte? What does const int mean? You mention deep copies, but you don't explain how const applies to deep copies. Are there any effects on implementation, or this a purely compile-time construct? What are the rules about unsafe type conversions to or from const types?

If this proposal is intended to add the C const qualifier to Go, then I doubt the proposal will be accepted.

Any change in this area for Go 2 is going to require experience reports as discussed at https://blog.golang.org/toward-go2 .

[ghasemloo]

Thanks for the link. I will read it and expand the proposal.

[ianlancetaylor]

We are not going to add the C style const type qualifier to Go. Closing.