Nice document; clearly you spent a while on it. I only briefly glanced over it.

Copies are the only way to achieve immutability in Go 1.x, but copies inevitably degrade runtime performance. This dilemma encourages Go 1.x developers to either write unsafe mutable APIs when targeting optimal runtime performance or safe but slow and copy-code bloated ones.

Not exactly the only way. An alternative approach is to have an opaque type with only exported methods that provide read-only access, which is how reflect.Type achieves immutability. The v2 protobuf reflection API also takes this approach. It has other downsides (like needing to manually create methods for each read-only operation), but pointing out that there are non-copy approaches to immutability.

I like the idea of mut more than const, but I think similar effect could be achieved with optional naming conventions (field_m, mField, field$ :-) and a go-vet switch.

Also forgetting to use const somewhere can cause havoc down the road...

EDIT: Related: #21130, #6386

@networkimprov please no $ in names, I don't think we need to start another PHP again

As far as I can tell in my initial skim, this doesn't solve the memchr problem. In C the standard library memchr function, which returns a pointer to the first occurence of a character in a string, is defined as char *memchar(const char *, char). The problem is that in terms of types, if memchr is passed a const char * it should return a const char *, and if memchr is passed a char * it should return a char *. That is, it should preserve the const-ness of its first argument. But there is no way to write that in C. And I don't see how to write that in your proposal.

Other comments:

• Is there any difference between this proposal and the use of const as a type qualifier in C, other than the logical extension to interfaces?
• Look up "const-poisoning."
• Pedantically, I don't particularly like using the word "immutable" to describe the parameter to func F(const []int). That slice is not immutable; all that declaration says is that F will not change it. This is particularly clear if you write func F(s1 const []int, s2 []int) and then call it as F(s, s). You can't say that s1 is immutable within F, because if s2 changes then s1 will change.
• Do we really have to worry about immutable containers of mutable values? Yes, that comes up once in a while, but it is often enough to make it worth writing const [] const T?

@dsnet
getters/setters are doing just that: they copy stuff from the inner scope of the struct. You
don't want to copy everything every time, and you certainly don't want to do it manually. Writing setters, getters, cloners just for the sake of ensuring immutability is not only quite tedious but also very error-prone due to pointer aliasing, which is the scariest part actually. Copy-code tends to be rather complicated in Go, one wrong copy (like copying a pointer, or naively copying a reference type such as a slice) and you've introduced aliasing that could have terrific, non-obvious consequences. With immutable types though, having read-only aliasing is just fine because there's no mutable shared state.

Currently, the safest way of avoiding manual copying of large structs are interfaces. You could define 2 interfaces where one of them lacks the mutating methods and return interfaces from the getters only. This is an "okay" solution, but it doesn't solve internal mutability problems. In big open source projects many people are working on the code, intentions must be unambiguous, clear and precise, which they're currently not. Can you automatically ensure that the methods implementing the read-only interface do not mutate the object for sure, even after merging a pull request from an external developer who's not fully aware of your intentions? You can't! You'll have to write proper unit tests and carefully analyze each and every commit! With immutable types you declare your interface methods immutable and you can be 100% sure that any implementation of it trying to mutate the object will fail the compilation. Apart from that, interfaces aren't free, they do have a slight runtime cost due to indirection, so having an option to avoid them for performance reasons while still preserving safety is a good thing!

I always prefer to solve these kinds of problems declaratively. I declare what is mutable/immutable while the compiler does all the dirty work of making sure neither me, nor my coworkers, nor the open source contributors sending in their pull requests shoot themselves in the foot introducing bugs. Isn't this the way compiled languages should make our lives easier?

@networkimprov
As section 3. of the design document clearly states: immutability by default and explicit mutability qualification through mut is preferable, but would only be possible in a backward-incompatible Go 2.x specification, which is not to be expected any time soon (AFAIK, the "Go 2" they're advertising is rather a Go 1.13+ because the folks at Google aren't big fans of breaking compatibility as it seems).

Naming conventions would break backward-compatibility. Old Go 1.x code could either stop compiling or fail at linting, which is unacceptable. This proposal aspires to preserve backward-compatibility at all cost. There's also a somewhat related question in the FAQ by the way.

You may want to read Russ' evaluation of a read-only slices proposal. It contains a lot of the issues that this proposal should grapple with.

getters/setters are doing just that: they copy stuff from the inner scope of the struct.

But they don't have to. If the inner field is a composite type, the getter can return an opaque type that internally holds a pointer to the composite type and only provides exported read-only getter methods.

Writing setters, getters, cloners just for the sake of ensuring immutability is not only quite tedious but also very error-prone due to pointer aliasing, which is the scariest part actually

I've written several immutable APIs in this way. I absolutely agree that it is tedious, but I personally don't think it was "very error-prone" from the perspective of the API author. Pointer aliasing is not inherently the problem; it is problematic if a pointer to a non-opaque type leaks to the public API. However, I find it relatively straight-forward to review the public API and reason that it doesn't violate immutability.

Can you automatically ensure that the methods implementing the read-only interface do not mutate the object for sure, even after merging a pull request from an external developer who's not fully aware of your intentions? You can't!

Since read-only APIs are usually just getters, they are not terribly complicated such that you would accidentally mutate the object (e.g., it is not hard to review this and reason it is read-only).

In big open source projects many people are working on the code, intentions must be unambiguous, clear and precise, which they're currently not.

An opaque read-only API does make the intention clear. The lack of any setter methods is a clear signal that the user should not (and cannot) mutate anything.

Apart from that, interfaces aren't free, they do have a slight runtime cost due to indirection, so having an option to avoid them for performance reasons

Interfaces are one such implementation, but it doesn't have to be. It can be a concrete type too:

type MutableStruct struct {
    Field int
    ...
}
type ImmutableStruct struct { p *MutableStruct }
func (p ImmutableStruct) GetField() int { return p.p.Field }

There is practically no runtime cost to this as the compiler can inline all the getters as if they were nested field accesses (or slice indexes, map lookups, etc).

I am bringing the technique up not as an end-all alternative to your proposal, but more so to counter the claim that "copies are the only way to achieve immutability ... [which] degrades runtime performance". It is a legitimate approach taken today to address this problem, which the proposal seems to gloss over.

I agree that there are disadvantages to opaque APIs with read-only getters (especially with regard to their tediousness and perhaps the lack of implicit casting), but I think it would help the case of a proposal trying to add immutability to acknowledge techniques done today to work around the problem and show that the benefit of adding immutability outweighs the cost (e.g., complexity in type system and the "const poisoning" mentioned earlier).

Naming conventions would break backward-compatibility.

Above I suggested a go-vet switch to support a naming convention. Such a convention would be optional, permanently. As would a mut keyword. Lots of folks don't want to code that way.

There has been plenty of discussion about const-ness over the years, yet the two priorities for Go2 are error handling & generics, and code for them presumably won't land for a couple years (there is no defined schedule as yet).

I love how well done the proposal is. Thank you for your hard work on this.

I have just one thought that I would like to share:
It is stated in the proposal that we can't cast an immutable var to a mutable one, as we could break the immutability. The opposite, casting a mutable var to an immutable one, can be done, which makes sense. However, in this case, we can break immutability. I know that you talk about this in section 4.5. How are constants different from immutable types?, but this could lead to very subtle and unexpected situations.

For example, let's say we have this Slice type:

type Slice []int

func (s *Slice) Add(elem const int) {
    *s = append(*s, elem)
} 

func (s const Slice) ImmutableVersion() const [] const int {
    return s
}

And then we use it like this:

slice := Slice{1,2,3,4}
immutableVersion := slice.ImmutableVersion()
// Now immutableVersion = {1,2,3,4}
slice.Add(5)
// Now immutableVersion = {1,2,3,4,5} It has changed

This behavior could be unexpected and lead to confusion, as you were guaranteed by the type system that the var immutableVersion was immutable.
This can be even worse with slices as, if the capacity is exceeded, append will allocate a new underlying array, what means that the immutableVersion won't be changed. So we don't really know if/when the immutableVersion will change.

This won't happen if the method ImmutableVersion() returns a copy.

Don't get me wrong! I love the proposal. I think it is the best one I have seen for immutability and I would like it to come true as soon as possible.

I just wanted to know the general opinion about the case I have posted.

Thanks!

In 2.6. Immutable Interface Methods I am not sure I understand why enforcement of mutability on the interface is important. This seems more like an implementation detail and could severely limit the usefulness of interfaces if abused too much. The answer in 4.7 doesn't make much sense to me.

@ianlancetaylor

The difference between C-style const and the proposed const

Is there any difference between this proposal and the use of const as a type qualifier in C, other than the logical extension to interfaces?

There is! The const in C is just confusing while the const in this proposal always targets the type on the right:

In fact, C-style const is so confusing that const char * is the exact same as char const *. You also can cast const to non-const in C, which you can't in this proposal. Please do not compare the const from C with the proposed const for Go, we don't wanna do it the horrible C-way, but rather learn from its mistakes!

Const-Poisoning

If by "const-poisoning" you mean the ability to cast immutable types to their mutable counterparts then I've got good news for you: C-style const poisoning is impossible with this proposal.

IV. Mutable types can be cast to their immutable counterparts, but not the other way around.

Terminology

Pedantically, I don't particularly like using the word "immutable"

This proposal is not about functional-programming-style "immutable objects", it's about "immutable types". Immutable objects remain immutable after they're initialized while immutable types are types you can't perform mutations on. "Types" and "objects" are obviously not the same and this proposal doesn't propose immutable objects.

Immutable Reference Types

Do we really have to worry about immutable containers of mutable values? Yes, that comes up once in a while, but it is often enough to make it worth writing const [] const T?

Reference types such as pointers, slices and maps shall be no exception in the concept of immutable types (slices and maps are reference types. Yes, they're implemented by a struct but to us users they're opaque). Section 5.2.1. describes why transitive immutability is to be avoided. Basically, it makes the entire concept of immutable types useless when the developer faces a slightly more complex situation like when a reference, such as a pointer, must point to an exact mutable object. But it's the complex situations the developers need the compiler's help most! Transitive immutability will force the developer to throw immutable types out the window because they limit his/her expressiveness making it totally useless.

@ianlancetaylor's 2010 blog post on const: https://www.airs.com/blog/archives/428

He describes const as compiler-enforced documentation, except for variable definition where it directs the compiler to use read-only memory. (And he discusses const poisoning.)

But there is another way that const can affect generated code; a const function argument can be passed by reference instead of by value, so that a compound object (Go struct or array) isn't copied onto the stack. (Go maps and slice contents are already passed by reference.)

I'd like to see Go support that kind of const.

@romshark Const poisoning refers to what happens when you add const to one function, and then you have to add const to every function that it calls, and then you have to add const to every function that those functions call, etc.

Then sometimes you discover that you have to change some lower function to not use const, for perfectly valid reasons, and const poisoning refers to the problem of removing const from the entire call chain.

These aren't made up problems, they are real issues that arise in practice in large programs.

Also, let me ask the comparison with C again: is there any difference between the use of const in this proposal and the use of const in C, other than syntax?

@ianlancetaylor
This is the reason Section 2.12. even exists. It's definitely true that once you've got immutable types you need to use them everywhere. This, essentially, is the price you pay for having predictability, clarity, and safety. It's kind of a stopper for the Go 1.x proposal, I agree, but in Go 2.x this must be done with immutable types by default to avoid having ambiguity from the very start and not end up with the Go 1.x problem of having to fix all libraries including the standard one.

I honestly can't imagine what "perfectly valid reasons" you need to have to, for example, make any of the lower functions called by strings.Join() not use const for the slice of strings you pass to a because a should be guaranteed to not be touched in any way neither by strings.Join() nor by any of the functions up the stack. And since immut -> mut casting is inherently forbidden I see no problems here. Once you provide a contract (API) - you either support it or you break it, not silently violate it!

Can you give us an example of when we'd suddenly discover that we actually needed mutable inputs and thus have to "remove immutability"?

There is no semantic difference between the C-style const and the proposed const. The proposed const is a better execution of the C version, but in the end, they both serve a similar purpose:

• make the intentions of the code author clear and reliable.
• protect the code from undesired and unexpected mutations.

Problematic cases happen in large, complex, programs, so there are no small examples. In terms of your proposal, the kind of thing that happens is that you start passing a map around, and there is no reason to change it, so you mark it const everywhere. Let's say it's a map of names to codes or something. Then later you realize that the names sometimes change, but you can only discover that deep in the call hierarchy. So you have to add some code there to change the map, and you have to remove const from all the callers. Obviously that is easy to nit pick, it's just an example, and, yes, I've seen this kind of thing happen in real code. In fact in C++ this is where most people reach for const_cast.

That aside, I note that you haven't replied to my memchr comment. In that regard you might want to read through #22876, which tries to address that problem through "permission genericity."

@ianlancetaylor
Yes, that is a problem indeed and the "permission genericity" concept proposed by Jonathan Amsterdam in #22876 does look promising (I wonder how I missed that). I'll give it a thought, it probably makes sense to integrate the concept of immutability genericity into this proposal as well.

I appreciate the thought that went into this proposal, however I think immutability is mostly an academic concern. Seeing how complex this proposal is, I'd like to hear of some experience reports where accidental mutation actually caused serious problems in a large Go code base. In my experience, accidental mutation is a relatively rare cause of bugs in programming. Therefore I think it does not warrant the troubles of having to use const constantly, or having to constantly worry about const correctness.

I appreciate the thought that went into this proposal, however I think immutability is mostly an academic concern. Seeing how complex this proposal is, I'd like to hear of some experience reports where accidental mutation actually caused serious problems in a large Go code base. In my experience, accidental mutation is a relatively rare cause of bugs in programming. Therefore I think it does not warrant the troubles of having to use const constantly, or having to constantly worry about const correctness.

I am more than reluctant to introduce more complex solution than the problem you're trying to solve. Go is a simple language to a certain extent, we don't need to copy other language just to make some swing.

I haven't seen any comments from those who've given a 👎, so here's my input.

Personally I don't like the idea behind const types. It reminds me of C's const which, IMO, was a disaster that complicated C's otherwise simple type system.

I am aware that it brings in a lot of safety, but it comes at the cost of a lot of readability. I also understand that sometimes sacrifices to readability need to be made to increase safety, but I'm not sure if this is one of them.

In fact in C++ this is where most people reach for const_cast.

In the C++ codebases I've maintained, the vast majority of uses of const_cast were in order to overload const and non-const member functions.

That technique is recommended in Effective C++ (and in this StackOverflow answer), but disrecommended in the isocpp.org core guidelines.

That seems to support the theory that const-parametricity is sufficient to avoid the need for such casts.

I didn't mean to imply it was the only time people used const_cast.

That does raise the problem of migration paths, though: there are widespread APIs today, such as io.Writer that accept read-write slices, and a naive approach to const in the type system would require at least one of:

• workarounds at every call site, such as conversions through unsafe.Pointer;
• escape hatches for calling existing (Go 1) APIs, such as (unsound) bivariant subtyping; or
• large-scale updates to ~all existing packages.

In contrast, a dynamic analysis (such as the one in #22048, possibly only enforced when the race detector is enabled) would only affect existing APIs that actually perform unexpected writes.

I'm not sure why you're bringing up io.Writer, @bcmills.

Mutable variables can safely be accepted as const and the API documentation for io.Writer itself attempts to convey its immutability requirements.

Languages that get this right start with immutable by default and do a lot of work behind the scenes to make everything seamless and need some syntax sugar to make it easy to use. I love immutability, but I don't think it'd really fit in to Go well.

I do want to provide my position on one of @ianlancetaylor's points, though.

[T]he memchr problem. In C the standard library memchr function, which returns a pointer to the first occurence of a character in a string, is defined as char *memchar(const char *, char). The problem is that in terms of types, if memchr is passed a const char * it should return a const char *, and if memchr is passed a char * it should return a char *. That is, it should preserve the const-ness of its first argument.

Let's say A is const char * and B is char *.

memchr(A, B) is fine.

memchr(A, A) and memchr(B, B) should both be type errors. Each should need an explicit step to transition to/from an immutable copy: something like memchr(A, mutable_copy_of(A)) and memchr(immutable_copy_of(B), B).

This is the same as if this were a Go func with the signature func memchr(string, []byte) []byte where A is a string and B is a []byte. You can't just call memchr(A, A) and have it be the same as string(memchr(A, []byte(A))).

This inevitably leads to needing (at least) two versions of everything to avoid copying everything dozens of time or not being able to use (im)mutable versions of types because a needed dependency made the choice for you.

Sometimes generics could help with that by letting you write multiple versions simultaneously, but that means making a lot of things generic that otherwise would not need to be, essentially swapping "const poisoning" with "generics poisoning".

Having freeze/unfreeze/isFrozen sidesteps this but adds a dynamic axis to a static type system. Instead of having two versions of each function you have one version that needs to cope with both at runtime.

@romshark I also had bad experience with C++ const poisoning, and it is not due to "bad design/API" but mere new features/requirements added, that need to modify something deep in the call chain, that nobody though should be modified before. And usually these features are needed for "yesterday", I did the only possible thing - const_cast right on the spot. So @ianlancetaylor concerns are very valid. One thought on all this const correctness thing: We have to declare that if something is marked as const in the current call chain, doesn't mean that it will not change by other part of the program running concurrently where they are not const types. It is just that current call chain can't change it ( unless you remove the const with something along the lines of const_cast ). Yeah, const correctness it is not a simple beast.

@jfcg let's say you want a factory that returns objects with an immutable field:

type Object struct { ID *const uint64 }

type Factory struct { counter uint64 }

func (f *Factory) NewObject() *Object {
  f.counter++
  id := f.counter                // Will be allocated
  return &Object {ID: &const id} // Pointer escapes function scope
}

This approach leads to a performance penalty.

The read-only type approach doesn't:

type Object struct { ID immut uint64 }

type Factory struct { counter uint64 }

func (f *Factory) NewObject() *Object {
  f.counter++
  return &Object {ID: f.counter} // No pointers, no allocations
}

This is an oversimplified example. I know that we could just return *const instead, but we might want the object to be mutable with only the Object.ID field being immutable.

package mypkg

type ConfVar struct {
   A int
   B string
}

var pkgVar ConfVar

func PkgVar() *const ConfVar {
   return &const pkgVar
}

Second issue: pkgVar remains mutable within the package, which might not be desirable.

package mypkg

type ConfVar struct {
  A int
  B string
}

var PkgVar = immut ConfVar{
  A: 42,
  B: "foo",
}

Read-only types would guaranteemypkg.PkgVar to be immutable since it cannot be written to from both within and from outside of the package.

type Object struct { ID immut uint64 }

type Factory struct { counter uint64 }

func (f *Factory) NewObject() *Object {
  f.counter++
  return &Object {ID: f.counter} // No pointers, no allocations
}

This is an oversimplified example. I know that we could just return *const instead, but we might want the object to be mutable with only the Object.ID field being immutable.

This case (or similar ones) does not even need read-only pointers, let alone full blown immutability:

type Object struct {
    id uint64
    Data string
}
func (o *Object) ID() uint64 {
    return o.id
}

Methods are perfectly fine and even they can be optimized out by compilers.

Second issue: pkgVar remains mutable within the package, which might not be desirable.

It is actually by design (for example). Only the package can update its confguration variables, sounds pretty straightforward to me.

package mypkg

type ConfVar struct {
  A int
  B string
}

var PkgVar = immut ConfVar{
  A: 42,
  B: "foo",
}

Read-only types would guaranteemypkg.PkgVar to be immutable since it cannot be written to from both within and from outside of the package.

What advantages do always-immutable variables have over typed constants?

Can you think of a real example where full blown immutability delivers undisputed advantage that struct methods, functions and read-only pointers cannot?

Was this issue addressed by someone from the core language team? I noticed that this is a 3 years old issue and in some way I would like to know if it is worth it to keep me hyped for constant custom datatypes. Having something readonly sometimes makes a huge difference in programming and also helps you at debugging very much.

Core team members have commented on this issue (e.g., see 1st comment by @ianlancetaylor). Virtually all language proposals are on hold while we're trying to get generics done.

@griesemer: Does the core team have a threshold, some measure of the interest of the community for an issue, in order to implement that issue? For instance, if a petition addressed to the White House is signed by at least 100000 citizens, the White House must provide a formal answer. Does the Go community have anything similar?

I took a quick look at the issues labeled with "Proposal-Accepted" and "Go2", and at those labeled with "Proposal-Accepted" and "LanguageChange", and this proposal has ratio of "supportive reactions" (expressed as emojis: thumb up, confetti, heart) to "dismissive reactions" comparable to all those proposals that got accepted (even better, in fact). This shows not only interest in the issue, but also that the community seems to back this proposal. This leads to an ethical dilemma: what if the core team disagrees with the majority of the GitHub Go community? Are these informal votes expressed as emojis binding for the core team in other ways than merely morally (which is quite loose)?

This leads to an ethical dilemma: what if the core team disagrees with the majority of the GitHub Go community? Are these informal votes expressed as emojis binding for the core team in other ways than merely morally (which is quite loose)?

I don't think there's much of a dilemma. It's an open-source project. If the users of the project by and large want something but the primary developers disagree, I would think that the best course of action would be for the people who do want the change to fork it and implement it. It seems a little strange to me to have them be 'bound' by the limited number of users of the language who actually pay attention to GitHub issues and proposals.

The White House, or really the general government, is only required to respond, not actually do anything else, based on a petition. The Go developers generally respond to pretty much every proposal, and they'll usually respond quite a lot to popular ones, especially if they heavily disagree with them. Though they won't be responding much at the moment as the whole team is on a social media vacation for the next few weeks.

@concastinator A number of people from the Go team have responded on this issue. If you just want a response, I think you have one. Indeed, you have several.

As far as "level of interest leading to implementation," then, no, there is no level of interest that in itself leads to implementation. There also has to be an idea that works well with the rest of the language. All language changes have costs as well as benefits. As I've explained in several comments above I think that this particular proposal has some significant issues that make it a poor fit for Go.

I personally would like to see a language or analyzer change that addresses at least some of the issues involving immutability in Go, but I have not yet seen a change that seems to have benefits that outweigh the costs. That is just my own personal judgement, of course.

Hi, I found this proposal just now, I’m using Go for only half a year now. Previously I used the D programming language for more than ten years and C even longer. Version 2 of the D programming language introduced a const/immutable feature very similar to the one suggested here, I have worked with it for years, so I’d like to speak a bit from experience.

Don’t do it.

Just don’t. You are opening a can of worms you’ll never be able to close again.

A const or immut qualifier looks unproblematic in short code examples, just a few simple extra rules, and it will work just fine. But this extension of the type system has much more severe consequences than these examples show. I’d like to provide a list of what I’ve experienced.

• Const-poisoning was an ever-ongoing major hassle.
• Once library authors started using it, libraries const-poisoned our programs sooner or later.
• Pointless const conversion glue code became a frequently used pattern in programs.
• Code needed to be repeated to accommodate for both mutable an const. The memchr problem mentioned above in proposal: Go 2: immutable type qualifier #27975 (comment) is one such example. D has very powerful metaprogramming, which automated this code multiplication. Go does not.
• Sometimes we resorted to unsafe code removing const because other solutions were not feasible.
• Composed types such as structs, arrays/slices, maps or function types lead to combinatorial explosion of the same type with differently qualified base types.
• To address unforeseen complications, more and more language features were added, each of which introduced more corner cases.
• The language became much more difficult to understand and less practical to use.

Here are a few examples of complications introduced by qualifiers.

// library code
func f(p *const int) {/* … */}

// user code
func g(f func(*int)) {/* … */}

g(f) // Will this compile? It should!

f can be called with an *int parameter so it should be possible to pass it to g. But are the function types compatible? If yes, what if f accepts another function accepting an unqualified pointer, or if f accepts a pointer to or channel or slice of function pointer?

func f(p *int) {/* … */}
func g(p *const int) {/* … */}

var a = [...]func(*int){f, g} // Will this compile? It should!

What about this case? a[i](p) may or may not write to *p so it should be allowed to have both f and g in the array. Still the function types differ. And again, the argument could be chan []*int vs. chan []*const int as well.

In D2 the memchr problem is addressed as follows:

func f(a *inout int) *inout int {/* … */}

inout is a magic qualifier that works like const inside f, but at the caller’s site the return type qualifier is the same as the qualifier of the inout argument. But what to you do with multiple arguments and multiple return values (which don’t exist in D)? How do you say, I want the first return type to have the qualifier of the second argument and vice versa?

Also, I’ve encountered situations which inout does not solve, like this:

type S struct{
    p *const int
}

(s *S) Set(p *const int) {
   s.p = p
}

(s *const S) Get() *const int {
   return s.p
}

Suppose we pass an *int to S.Set() and get it back with S.Get(). It will be const, no matter what it was initially. But what if we need it to be the same qualifier? We can’t because the const-ness of the return value of Get would need to change at run-time to match the most recent Set call. If a D user encounters this situation then the consequence in practice is to write unsafe code and cast the const away because duplicating S and all its methods or re-designing this part of the project is not feasible.

How will this work with a type assertion or switch? Will an *int match x.(*const int), too? Probably yes, but what about composed types?

Finally, the burden imposed on the programmer it cannot be underestimated how much unnecessary bureaucracy type qualifiers bear because of the incompatibilities they cause if not used with much care and far-sighted planning. That is not to mention the potential for bikeshedding in code review.

Last words. I have used C and D earlier, each for many years. Changing to Go was an indescribable joy from the beginning because so many things causing subtle bugs and unnecessary interference with the actual task of implementing functionality have finally been done right. Simple things are reliably simple and safe. The absence of type qualifiers is a big part of it.

So don’t do the same mistake. Leave type qualifiers out.

[Edit] Bonus: interfaces as an impression of the additional burden of decisions const puts upon language and library designers and users.

Only const methods can be called with a const object so const is caller-friendlier. However, this restricts the method implementation: an additional design decision to make.

Should error.Error() be const or not? Shouldn’t returning const error be the new convention anyway—one shouldn’t manipulate a given error in hindsight, should one?

I’m happy to give pages of more examples if interest is there.

PS. Type qualifiers in the D programming language

@edvdavid Thanks for the report. That is very helpful.

Yes, thank you. Very thorough, thoughtful, and helpful.

Having watched const qualifiers arrive in C a long time ago, and all the trouble they caused, just like the ones you list here, I would have hoped subsequent language designers would leave const-ness out of their type systems. We did that for Go, but we were not language designers, just programmers designing a language.

I do most of my professional coding in F#, but I also use GO. Here's my 2 cents on this proposal.

As a long time F# programmer, I vote for immutability by default with explicit use of a mut keyword. I've developed/maintained/refactored dozens of enterprise critical F# applications in the last decade. From my experience, having immutability by default truly does improve code simplicity/readability, code safety/correctness (especially with concurrent programming), and ease of refactoring. I use the F# mutable keyword sparingly. When I do use it, it's for local/private use only.

I think it's great that go is getting generics and would like to see immutability by default some day. I do understand that adding too many new language features, especially those with limited real world benefit, is counter productive to the original GO language design goals. Given the GO language promise of backwards compatibility, perhaps immutability by default could be implemented in the future via an opt-in compiler option (maybe in conjunction with the compiler's -lang version option).

Lastly, thank you to the GO team for all your hard work.

I agree with psantoro: immutability by default is safer and allows for more optimizations.

I think that immutability by default is definitely the right way to go. However, that would be an extremely large change, as well as not being backwards-compatible.

In my experience, especially if it makes for a better experience overall, backwards compatibility tends to be overrated. To put this into an analogy everyone can understand, so many of the issues people associate with the Microsoft operating system which don’t exist on Mac are directly related to backwards compatibility. Meanwhile, Apple is not afraid to say “Yeah, the previous system may have been good for its time and it might be inconvenient for some developers to make the updates but it’s a one-time cost and makes for a better system for the ultimate users.”

backwards compatibility tends to be overrated

I largely disagree here. The last thing we would want is a "python 2 vs python 3" stagnation, granted a bit more went into that other than a backward compatibility issue. In terms of Java, they made some backward-incompatible changes between LTS releases (8 and 11). We are now on Java 17 and a huge portion of companies (even modern ones) are still using Java 8.

Sure, it is a "one-time cost". However, we cannot feasibly promise backwards compatibility, then require nearly every library author, tool author, company, and really every user of the Go language, to rewrite all of their code. Sure, we could say that they don't need to rewrite their applications, and that libraries written in older versions of Go would have all exposed functions and types be imported as if they were all mut types. But that is not a good solution.

As I tried to show in my speech above, I don’t think it is possible to add useful backwards-compatible immutability to a system which has been designed based on mutability by default. To be useful and not harmful, immutability is too deep a structural difference.

C++ keeps backwards compatibility at all costs, at least the last time I looked at it, including astronomic compilation times because the preprocessor is still supported and obvious nonsense such as virtual int f() = 0.

In general, backwards compatibility has always a scalability limit beyond which it adds more damage than benefit. Obstructing progress and innovation can quickly be a higher price to pay than starting from scratch. For example, for backwards compatibility reasons, both the mass ounce and the mass ton have each three different definitions.

I always thought of Go as a shining example of favouring innovation and progress over backwards compatibility – one could still do everything in C, with perfection in backwards compatibility as well as unreadable code when using a C library to manage multiplexed I/O with coroutines and synchronising FIFOs.

Go, the most Unixian programming language since C, breaks holy C/Unix compatibilities such as pointer arithmetic (unsafe guarantees no compatibility), null-terminated strings or the C calling convention, the latter being well known for the mess when trying to pass types which don’t exist in C. And main returns no value.

Go may break compatibility with C, but it does not break compatibility with itself. See https://golang.org/doc/go1compat. I believe this is essential for Go's success.

@ianlancetaylor As far as I can tell, that document doesn’t actually say Go will never break backwards compatibility.

From my perspective of mainly using C, and only occasionally Go, there is really only one scenario where I make much use of 'const', that is for a assigning a name to an expression within a block which I then know can not change later in the block.

This is for aid in comprehension, especially when coming back to the code some time later, so something like:

void function (void)
{
...
    while ( some_condition() ) {
...
        bool const is_a_green_fish = is_a_fish(x) && is_green(x);
...
        /* some later expression uses 'is_a_green_fish' */
    }
...
}

Hence this is a variable which can not be reassigned later in the block, and I'm expecting a later compiler error to enforce that such that I reduce the mental state I'm carrying while reading code.

I suspect that could be achieved with a 'let' (or maybe 'once') keyword operating just like 'var' but with the semantic check phase of the compiler enforcing the no subsequent reassignment constraint, but I suspect there may be niggles with reference types.

Or possibly just allowing the existing 'const' to be used within a function to assign from an arbitrary expression (e.g. another function call), not just from a compile time constant expression.

i.e. in the following both 'j' and 'xyz' would be treated as if they had been declared 'var', with the difference that a subsequent reassignment would be a compiler error:

func something() int {
	return 8
}

func main() {
	for i := 0; i < 3; i++ {
		const j = i + 3
		fmt.Println("i: ", j)
	}
	const xyz = 2 + something()
	
	fmt.Println("xyz: ", xyz)
}

The only other places where I occasionally use const in C is for an object to be allocated in read only memory by the linker (file scope definitions), and sometimes in leaf functions if it can aid documentation / comprehension, bearing in mind that one can escape const-ness on structs even without casts. It is the latter which is in part desired here, but one can never trust it anyway, so it has little real value, and the aforementioned poisoning issue.

As to mutable vs non mutable data, I actually quite liked the way that worked in the Objective-C Foundation classes, with paired classes. However that does depend upon classful inheritance behaviour for calling immutable methods on a mutable value.

The option to optimise the compiler code generation for methods with non pointer signatures such that they can pass by reference under the covers, while still preserving pass by value semantics sounds helpful. i.e. the method would simply use the implicit pointer in the ABI as long as no assignments occurred to the value, if the value was assigned to, then code would be generated such that a complete or partial copy could be made within the method itself - so preserving pass by value semantics.

As far as I can tell, that document doesn’t actually say Go will never break backwards compatibility.

Perhaps not, but it takes a clear engineering position: Go will only break backward compatibility for an awfully good reason.

By comparison, C has not broken backward compatibility since the first C standard in 1989. C++ has not broken backward compatibility since the first C++ standard in 1998, if we ignore the effect of additional keywords. Jave has, to the best of my knowledge, never broken backward compatibility at all. This approach has clearly worked well for these languages, all of which remain very popular. I think that Go should aspire to the same level of dependability.

Jave has, to the best of my knowledge, never broken backward compatibility at all

Java is planning on breaking certain unsafe reflection operations "in the future", but haven't done it yet. Currently, performing one of these unsafe operations will print a message to stderr.

There are already many related proposals, and I think here is a better place to put my thoughts on.

First I don't think using same keyword for different concepts is a good idea, as other languages have showed. There are as least several concepts mixed here, immutable vs readonly view, and use them as storage class vs type qualifier. For their differences, I like D's description.

For Go's const keyword, it is used as Immutable Storage Class as in D. It is a property of an object, which means it is immutable throuth out it's lifetime after initialization. Readonly views are different, the object can still be mutated by other references, it is a property of the assigned variable. As of type qualifier, we don't have a const int type but const int value in Go.

So I would like to extent const in Go to all types of objects as in #6386, like what D does for immutable storeage class. It is transitive and addressable, shadow copied to a var can modify that level's value, but not nested ones. Unlike D, casting of mutable to immutable should not be allowed, or atleast without using unsafe, so all nested value of an const object should either be const or copied in when initialization, or maybe unique reference at the time too. Like D, package level
const should be constant expression evaluated at compile time, others could be evaluated at runtime, but check at compile time. For implementation, all references of a const must not appear in left hand side, compiler could record which parameter is modified in function meta data to assist implementation.

For readonly views, D use the const keyword, since Go already use that for immutable, it should not be use for this purpose. I think a compiler intrinsic function could be a good fit: func ReadOnly[T any](T) T. There is a noescape function in the runtime works like this. I believe this could solve many problem mentioned in the Evaluation of read-only slices proposal and better express the intention. Immutable express constructor's intention, and readonly view express the caller's intention when using in a function parameter, not the callee's.

Take io.Writer for example, it's the caller's intention for the callee not to modify the provided buffer, so something like (*reciver).Write(constrains.ReadOnly(buf)) is used. But the caller could also provide a large buf for the writer to modify inplace. Whether the writer satisfy the readonly constrain can then be verified at compile time. A constrains.IsReadOnly can also be use for specialization at compile time.

The constrain is scoped, so the return value's writability is the same as before calling constrains.ReadOnly, not as the referenced passing in argument. This way, a return subslice of a readonly view of a slice can be writable, if it's writable before the call, which usually is what the caller want. Like in trimed := bytes.TrimSpace(constrains.ReadOnly(line)), trimed will be writable if line is writable in caller before the call. This could be more clean than D's inout.

Avoid using const and readonly as type qualifier could solve the const poisoning problem. The public type and function signatures are the same for const or readonly or not, just like we could pass in a const or var to the same function in Go now, and we don't have to write exponential number of one line adapter for every combination even if the underlying implementation is the same. Instead, constrains.IsConst and constrains.IsReadOnly can be use for compile time specialization.

Other properties mentioned in #24889, like restrict, which could help auto-vectorization, can be implemented as intrinsics like constrains.ReadOnly, without breaking backward compactability too.

Edit:
In short:

• Immutable storeage class is constructor saying no one should modify this.
• Readonly view is the caller saying the callee should not modify this.
• Use as type qualifier in function signature is the callee promise not to modify this.
• Use as type qualifier in struct signature is relaying constructor saying no one should modify this.

I personally feel immutabilty must be added to go , even if not be default.we could introduce a new keyword imm similar to const & var to declare immutable struct.

As a huge fan of the simplicity that's currently made available by Go, I'll throw my two cents in the pot. While it's clear the proposer spent a lot of time and effort working this up, this is really just a matter of adding syntactic sugar really.

To the core team, thank you so much for being so determined to keep the language simple, whilst listening to your community. Go is an amazing programming language. I use it every day at work, and hope that the language stays as simple as possible as the years progress. Let's not let the features win, haha! Absolute features corrupt absolutely.

PLEASE add immutability. more important than generics were imho. this would make a huge diff in large software projects where there exists no strong way of ensuring data is read-only

I'd like to hear of some experience reports where accidental mutation actually caused serious problems in a large Go code base

Hi, chiming in to provide current woes of a somewhat large Go code base (>1,000 packages with ~2million lines not including dependencies), currently struggling with accidental mutation. We currently have situations where a struct contains a map (or slice or some other pointer-backed data) which is widely used throughout the codebase. At some point, that struct is passed to a utility which believes it is the owner of that instance of the struct and mutates it in some way (writes to a map, appends/writes to a slice, changes a pointer etc). This causes those mutations to be seen by other holders of that variable. This bugs are very difficult to track down and often present as unexpected and surprising behavior requiring a lot of time spent debugging.

We've had to resort to deep copying these maps/slices/etc so that each caller does not mutate another's held copy accidentally. For large objects, this can balloon memory and be rather slow (it routinely shows up in our pprof graphs). It would be much better to have the option to enforce read-only structs/pointers/etc. It also causes a bit of a dependency nightmare where you must ensure that any sub-struct contained within a struct is also responsibly doing a deepcopy.

I'm not a huge fan of the proposed syntax, however. I find it interesting that Go has already solved this problem for channels via <-chan and chan<-. I'd like to at least entertain the idea of extending that paradigm to types:

type myStruct struct {
	names map[string]string
}

func readOnly(m <-myStruct) {
	readOnlyMapFunction(m.names)
...
}

func readOnlyMapFunction(names <-map[string]string) {
...
}

in which reads would be allowed, but writes expressly denied.

This does present the problem of const-poisoning as others have mentioned. But even in a codebase as large as the one I work in, I would take that tradeoff.

With the usage of const as a modifier, there's been some confusion regarding its position and usage. What if instead of a modifier, a naming convention was used? The idea that's been floating around in my head recently is to allow ! to be used in identifiers, much like it is in Ruby, and say that any var, which includes receivers and arguments, that has a name that ends with ! would be immutable. That not only fits in well, in my opinion, with capitalization denoting visibility, but it would solve several questions of syntax:

var a! int
a! = 3 // Error.

a!, b := f()
a! = 3 // Error.
b = 3 // Allowed.

a! := 3
b := a! // Allowed because simple types copy.

a! := "An example."
b := a! // Allowed because strings are also immutable anyways.

a! := []byte("An example.")
b := a! // Error.

var a A
b! := a // Allowed for everything because immutability is only a guarantee that that variable can't be used to change something, not a guarantee that it won't change ever at all.

// Returns can't be immutable because of how defer works.
func (a! A) Im(b! B) (c C) {
  return a! + b!
}

p := &a! // Error. Can't store address of immutable variable in mutable variable.
p! := &a! // Allowed.

var a! struct { b! int } // Error. Struct fields can't individually be immutable.

var a! struct { p *int }
p := a!.p // Error. a!.p is immutable just like a! is.
p! := a!.p // Allowed.

*p! = 3 // Error.

m! := make(map[any]any)
f(m![3]) // Allowed.
m[3] = 2 // Error.
m2 := m! // Error.

var a! [3]int
s := a![:] // Error.

type A int
func (a A) M()
var a! A
a!.M() // Allowed.

type A int
func (a *A) M()
var a! A
a!.M() // Error.

type A struct { p *int }
func (a A) M()
var a! A
a!.M() // Error.

And so on.

Unfortunately, those last ones mean that without code migrating to this manually, that feature just won't be too useful, as making a variable immutable would limit you to only being able to call methods that expect it to be possible for it to be immutable. Existing code that hasn't changed its receivers to have a ! would just simply not work with it.