In Go, what does the composite literal &Point{X: 1} evaluate to?

## Taking the address of a literal In most expressions Go's `&` operator requires an addressable operand: a variable, a pointer dereference, a slice element, a field of an addressable struct. A composite literal is a specific, spec-blessed exception — `&T{...}` is legal for a struct, array, slice or map literal, and it means "allocate a new `T`, initialise it from this literal, and give me its address". So `&Point{X: 1}` is shorthand for: ``` tmp := Point{X: 1} ... &tmp ``` with no name for `tmp`. The initialisation rules are the ordinary composite-literal rules: fields you name get your values, fields you omit get their zero values, so `&Point{}` is a pointer to a fully zeroed `Point`. ## Why constructors look like this Go has no constructors, so a package that wants to hand out an initialised value exposes a function that returns one. When the value must be shared, must be mutated by its methods, or is large enough that copying matters, that function returns a pointer, and its body is almost always a single `&T{...}` expression: ``` func NewEncoder(w io.Writer) *Encoder { return &Encoder{w: w} } ``` The alternative spellings all read worse. `new(Encoder)` returns a `*Encoder` but cannot set `w`, so you would need a second statement. A named temporary plus `&tmp` adds a line and a name that carries no information. ## The & does not decide where it lives A very common misreading is that `&` means "heap". It does not. Go's compiler runs escape analysis: if it can prove the value's lifetime ends with the enclosing function's frame, it allocates it on the stack even though you took its address; if the pointer escapes — returned, stored in a longer-lived structure, captured by a goroutine, passed to something the compiler cannot see through — it is heap-allocated. `go build -gcflags=-m` prints the decision per site, in lines such as `&Point{} escapes to heap` or `&Point{} does not escape`. The practical consequence is that a helper that builds `&Point{...}` and only reads it locally can be allocation-free, and that you should measure rather than assume. ## Elision inside an outer literal Inside a composite literal for a slice, array or map, an element that is itself a composite literal may drop the repeated type. Two forms exist and they are easy to conflate: * When the element type is `T`, the inner `T` is elided: `[]Point{{X: 1}, {X: 2}}`. * When the element type is `*T`, the whole `&T` is elided: `[]*Point{{X: 1}, {X: 2}}`. The second is the one that surprises readers, because there is no visible `&` anywhere and yet each element is a distinct pointer to a separately initialised `Point`. The same elision works for map values, so `map[string]*Point{"origin": {}}` is a map to a pointer to a zeroed `Point`. Nothing is shared between the elements: each inner literal allocates its own value. ## Value or pointer? Deciding between returning `T` and `*T` is an API question that outlives the syntax, but the composite-literal forms make each cheap to write. Reach for `&T{...}` when callers must observe mutations made through the value's methods, when the type carries something that must not be copied, or when the value is genuinely large. Reach for `T{...}` when the value is small and behaves like data, since a value costs no indirection and cannot be nil at the call site. ## Checking what you built When a construction site is suspect, print it. `fmt.Printf("%+v\n", p)` on a `*Point` prints `&{X:1 Y:0}` — the `&` prefix tells you it is a pointer, the field names come from `%+v`, and the zeros show which fields your literal did not set. `%#v` goes further and prints the Go-syntax form, `&main.Point{X:1, Y:0}`, which you can paste back into code. Both are the fastest way to confirm that an elided literal inside a bigger structure really initialised the fields you assumed it did. ## Relationship to new `new(T)` and `&T{}` produce the same thing: a pointer to a zeroed `T`. `&T{...}` additionally initialises fields. Modern Go code therefore uses `&T{...}` for structs and keeps `new` for the handful of cases where there is no useful literal — `new(int)`, for instance, when an API wants a `*int` and you have no variable to point at.