When you walk a struct with reflect, how do embedded fields appear and how do you reach their promoted fields?

## What the walk actually sees Embedding writes a type into a struct with no field name: ```go type Audit struct { CreatedBy string `db:"created_by"` } type User struct { Audit Email string `db:"email"` } ``` `reflect.TypeOf(User{}).NumField()` is **2**, not 3. `Field(0)` is the `Audit` field itself: `Name` is `"Audit"` (the type's name stands in for the field name), `Anonymous` is true, `Type` is the `Audit` struct type, and `Tag` is whatever was written on the embedding line — embedding can carry its own tag, and that tag has nothing to do with the tags inside `Audit`. This trips up tag-driven tools written without embedding in mind. A generator that emits one column per `db` tag sees two fields, finds a `db` tag on only one of them, and produces a mapping that is missing `created_by` — silently, because a struct field with no `db` tag is not an error condition in most walkers. ## Recursing yourself The manual fix is to descend when the field is embedded and struct-shaped: ```go for i := 0; i < t.NumField(); i++ { f := t.Field(i) if f.Anonymous { ft := f.Type if ft.Kind() == reflect.Pointer { ft = ft.Elem() } if ft.Kind() == reflect.Struct { walk(ft) // collect the promoted fields too continue } } // ordinary field } ``` Two details matter. An embedded field need not be a struct — you can embed an interface or a named non-struct type — so guard on the Kind before recursing. And you must recurse only on `Anonymous` fields: a *named* struct field is a nested value, not a promotion, and flattening it would invent columns the language never promoted. ## Letting reflect do it `reflect.VisibleFields(t)` returns all the fields that are visible on `t`, in breadth-first order, including the embedded struct fields themselves and the fields promoted through them. Each returned `StructField` has an `Index` describing how to get there. It applies Go's own visibility rules, which is its real advantage: shadowing and ambiguity are resolved the way the language resolves them, not the way you re-implemented them. ## Index and FieldByIndex For a directly declared field, `Index` has one element. For a promoted field it is a path: `CreatedBy` in the example above has `Index == []int{0, 0}` — field 0 of `User`, then field 0 of `Audit`. `Type.FieldByIndex(index)` and `Value.FieldByIndex(index)` follow that path. On the value side there is a hazard: if a step is an embedded *pointer* that happens to be nil, `Value.FieldByIndex` panics, because it would have to allocate to continue. `Value.FieldByIndexErr` exists precisely for that case and returns an error instead. ## FieldByName and ambiguity `Type.FieldByName("CreatedBy")` returns `(StructField, bool)` and does resolve promoted names, applying the same rules the compiler applies to a selector: the shallowest depth wins, and if two fields at the same shallowest depth have the name, the selector is ambiguous and the lookup reports `false` rather than picking one. Shadowing works the same way — a `CreatedBy` field declared directly on `User` hides the promoted one, and `FieldByName` returns the outer one with a one-element `Index`. ## Policy questions a walker has to answer Once embedding is in play, a tag-driven tool has to make explicit decisions that were invisible before: does an embedded struct flatten into the parent's namespace, or does it get a prefix? Does an embedded unexported type still contribute its exported promoted fields? What if the same tag value appears twice after flattening — is that an error, or does the shallower one win? None of these have a single right answer, but a walker that never states its answer produces output people cannot predict, and the surprises land months later when someone adds an embedded type to a struct that has always worked.