Here's the proposed feature:

type Node struct* {
  Left Node
  Right Node
}

var n Node = nil // not the same as a zero value.
n.Left = ... // runtime-panic
n = Node{}
n.Left = ...
n.Right = ...

var n2 = n
n2.Left = ... // This won't affect `n`.
n2.Left.Left = ... // compile-time error, n2.Left is not addressable.

n.Left = n // circular references are OK.

Without this proposal, performance often dictates whether I refer to a struct by value or reference, even when the struct is meant to be immutable. With this proposal, the only thing I would worry about is the security model.

The * comes after struct, so as to not conflict with *struct{...} which is a pointer type. struct*{...} is a (pointerized) struct type, and reflect would mostly treat it the same as a struct{...}, but reflect.ValueOf(struct*{...}).IsPointerized() == false. A pointerized struct type could still be mutable... var a *struct*{...} = &struct*{...}.

Here's one way to mix pointerized structs w/ mutable structs & mutexes.

type foo struct* {
  Value interface{}
}
func (f foo) GetValue() interface{} {...}

type Foo struct {
  mtx sync.RWMutex
  foo
}
func (f *Foo) SetValue(interface{}) {...} // Lock/Unlock
func (f *Foo) GetValue() interface{} {...} // RLock/RUnlock

f = Foo{...}
f.SetValue(...) // ok, f is addressable
g := f
g.SetValue(...) // ok, g is addressable
func cp(f Foo) Foo { return f } // returns a non-addressable copy
cp(g).SetValue(...) // compile-error, not addressable.
cp(g).GetValue(...) // calls foo.GetValue, mtx not needed

In the current behavior of Golang, the last line would not compile because type Foo hides the foo.GetValue method. I'm not sure what the consequences are of allowing this in general, but it seems useful for this purpose.

Context

You might have seen the rule of thumb for values-vs-pointers: if your struct has few fields, and you don’t need to mutate it, then you don’t need to use pointers. On the other hand, if the struct has too many fields, then you might want to use pointers. I find it difficult to always tell ahead of time whether structs ought to be pointers or not, but recently I discovered a nice way to work around the performance problem:

type BigStructWrapper interface {}
type BigStruct struct {...}

// cpy is immutable but this is slow.
// I've tested this w/ benchmarks and very large
// structs that are nested many levels.
{
  var str BigStruct = BigStruct{...}
  var cpy BigStruct = str
}

// cpy is still immutable and this is fast.
{
  var str BigStructWrapper = BigStruct{...}
  var cpy BigStructWrapper = str
}

Interface values are like pointers, but the value of an interface is not addressable so you can't mutate an interface value's shallow fields unless it's a pointer.

This shows that Golang can already optimize the copying/assignment of immutable structs by allocating them on the heap. The downside is that the code gets ugly (e.g. bigStruct.Field, not bigStructWrapper.(BigStruct).Field). Thus this proposal.

This is part of a set of proposals to improve Golang's security model