In Go's reflect package, what is settability and how is it obtained?

What's really being asked

This question probes whether you understand the difference between a value copy and an addressable location in Go's reflection system. It separates candidates who treat reflect.Value as a generic container from those who know it is a typed wrapper around an actual memory address. The interviewer cares about your mental model of addressability and why reflection cannot bypass Go's pass-by-value semantics.

The full answer

First, define settability as the property of a reflect.Value that indicates it refers to an actual storage location that can be mutated, not a transient copy. Second, explain that you obtain a settable Value by passing a pointer to the original variable into reflect.ValueOf and then calling Elem to indirect through the pointer. Third, note that slice elements and map values obtained through reflection are also settable because they refer to storage inside the backing array or hash table. Fourth, state that calling Set on an unsettable Value triggers a panic because the Value holds a copy of the original data with no underlying address to write to. Fifth, mention that you should check CanSet before calling Set in defensive code.

The mistakes people make

A major red flag is claiming that any reflect.Value returned by reflect.ValueOf is settable. Many candidates forget that ValueOf on a variable gives a copy, so calling Set panics immediately. Another mistake is confusing reflect.Type, which is never settable, with reflect.Value. Some candidates also think you can make a Value settable by copying it or by using a new Value constructor, which is incorrect; settability is determined at creation time based on whether the value was addressable.

What usually comes next

The interviewer may ask how you would modify a struct field through reflection, which requires obtaining a pointer to the struct, reflecting it, calling Elem, then FieldByName, and checking CanSet before Set. They might also ask why unexported fields cannot be set even with a pointer, which touches on package boundary enforcement by the reflect package. Another follow-up is comparing map assignment via reflection to direct map assignment, or asking about the performance cost of reflection-based mutation.

A concrete example

Imagine you have var x int = 5 and you want to change it to 7 via reflection. If you write v := reflect.ValueOf(x), then v.Set(reflect.ValueOf(7)) will panic because v is a copy of x and is not settable. The correct approach is v := reflect.ValueOf(&x).Elem(), which gives you a Value that points to x itself. Now v.CanSet() returns true and v.Set(reflect.ValueOf(7)) succeeds, changing x to 7. If you skip Elem and try to Set on the pointer Value itself, that also fails because the pointer Value is not settable; you must indirect to the element it points to.