Is Go Finally Adding Immutable Types After an 8‑Year Dormant Proposal?

Pain Point: The Cost of Defensive Copies

In Go 1.x, protecting data often requires returning a defensive copy, which incurs both memory allocation and runtime overhead. For example, exposing a slice of servers safely involves creating a new slice and copying the contents before returning it:

type Config struct {
    Servers []string
    // ...
}

// Current approach: return a copy for safety
func (c *Config) GetServers() []string {
    out := make([]string, len(c.Servers))
    copy(out, c.Servers)
    return out
}

This pattern leads to two major issues:

Performance loss: each access allocates memory and copies data, which is unacceptable on hot paths.

Semantic ambiguity: returning the original slice would be faster, but the compiler cannot enforce read‑only access, relying only on documentation.

As proposal author romshark puts it, the current options are either unsafe (returning a pointer) or inefficient (defensive copy).

Proposal Core: The immut Qualifier

The #27975 proposal suggests introducing a new type qualifier, initially considered as an overload of const and later leaning toward a dedicated immut keyword, to let the compiler enforce a read‑only contract.

Example of the envisioned syntax:

// Define a read‑only slice type
func ProcessData(data immut []byte) {
    // Reading is OK
    fmt.Println(data[0])
    // Modification is a compile‑time error
    // data[0] = 'X' // Compile Error: cannot assign to immutable type
}

The qualifier would also enforce assignment restrictions (an immut value cannot be assigned to a mutable variable) and transitivity (all fields of an immutable struct become immutable).

Community Debate: Ideals vs. Reality

The discussion thread became a "design‑philosophy battlefield" with core contributors like Ian Lance Taylor and Rob Pike weighing in.

const Contamination

Ian Lance Taylor warned that marking a low‑level function parameter as immut would force every caller up the stack to also be immut, leading to pervasive keyword pollution and a "const‑correctness" nightmare when later modifications are needed.

The io.Writer Dilemma

Contributor bcmills highlighted a compatibility problem: the existing io.Writer interface defines Write(p []byte). Changing the signature to Write(p immut []byte) would break all existing implementations, while keeping it unchanged would prevent passing read‑only slices safely.

What Does “Immutable” Actually Mean?

jimmyfrasche

pointed out that in C++, const T& only guarantees a read‑only view, not that the underlying data cannot change elsewhere. If Go were to enforce true immutability, it would need an ownership system similar to Rust, which represents a massive change to the language.

Why the Proposal Is Resurfacing in 2026?

Three forces have pushed the idea back onto the agenda:

Generics as a “permission generic” : With Go 1.18’s generics, the community can express mutability as a type parameter, potentially avoiding the io.Writer dead‑end.

Performance pressure : High‑performance use‑cases (databases, AI inference) demand zero‑copy data sharing, making a safe immutable view attractive.

Safety demands : Data races remain the top source of bugs; developers seek compile‑time guarantees beyond go vet and the race detector.

Using generics, a “permission‑generic” writer could be expressed as:

// Hypothetical permission‑generic interface
type Writer[T ~[]byte | ~immut []byte] interface {
    Write(p T) (n int, err error)
}

This design would allow both mutable and immutable byte slices to be passed safely, and existing implementations like bytes.Buffer would be treated as a specialization of the generic constraint without runtime overhead.

Future Possibilities: Gentle Evolution

Even if a full immut keyword proves too disruptive, several milder alternatives are being discussed:

Read‑only views : Introduce a generic wrapper ReadOnly[T] or a built‑in view type that provides a non‑modifiable façade.

Pure‑function annotations : Mark functions as side‑effect‑free, enabling more aggressive compiler optimisations.

Enhanced static analysis : Extend go vet with annotations or naming conventions to check immutability constraints without changing the language spec.

Conclusion

The revival of proposal #27975 signals that the Go team continues to explore ways to enrich the language’s expressive power while preserving its core value of simplicity. The debate highlights the classic trade‑off between performance, safety, and language complexity, reminding us that every new feature carries hidden costs.