In a Go struct that embeds two types both declaring Draw, how is d.Draw() resolved?

## The rule in one sentence For a selector `x.f`, Go looks for `f` at the shallowest depth in the type where any `f` exists. If exactly one candidate sits at that depth, that is the one. If two or more do, the selector is illegal. Depth is just how many embedded fields you traverse: a name declared on the struct itself is depth 0, a name promoted from a directly embedded type is depth 1, one promoted through two levels of embedding is depth 2, and so on. ## Shadowing is silent and often what you want ```go type Grid struct { Title string } type Pane struct { Grid Title string // depth 0 wins } ``` `p.Title` is the `Pane` field. Nothing warns you, and nothing is wrong: this is the deliberate mechanism for replacing part of an embedded type's surface. The shadowed one has not vanished — `p.Grid.Title` reaches it, and that explicit form is how a shadowing method delegates to the thing it shadowed. The same rule applies to methods. Declaring `func (p Pane) Draw()` when the embedded `Grid` already has `Draw` means `p.Draw()` calls yours. Depth, not declaration order, decides; reordering the fields in the struct changes nothing. ## Ambiguity is a compile error, not a silent pick Embed two types that offer the same name at the same depth and Go refuses to guess: ```go type Grid struct{ Rows int } func (g Grid) Draw() {} type Border struct{ Rows int } func (b Border) Draw() {} type Pane struct { Grid Border } ``` `p.Draw()` and `p.Rows` are both ambiguous selectors and will not compile. Many languages resolve a collision like this by declaration order or by a linearisation rule; Go has no such rule and does not want one, so the engineer arriving from another language sees a build break where they expected a winner. ## The error appears at the use site, not the declaration This is the part that surprises people. Declaring `Pane` above is perfectly legal. You can construct it, assign it and pass it around. The compiler complains only: - where a `p.Draw()` or `p.Rows` selector is actually written, and - where `Pane` is checked against an interface requiring `Draw`, because the ambiguous name is not in `Pane`'s method set. The message there is the usual missing-method complaint, which is a confusing way to be told about a collision two levels away. So a library can ship a struct with a latent ambiguity and only break the caller who first reaches for that name. It also means adding a method to one embedded type can break a distant call site that was compiling yesterday. ## Three ways out 1. **Qualify the selector.** `p.Grid.Draw()` names the one you meant. Always available, and the right fix when the collision is genuine and rare. 2. **Declare the name on the outer type.** A `func (p Pane) Draw()` at depth 0 outranks both candidates and makes the short selector legal again; inside it you call `p.Grid.Draw()`, `p.Border.Draw()`, or both, in whatever order the type actually means. 3. **Stop embedding one of them.** Give it an ordinary field name — `border Border` — and reach it through that name. This is usually the honest answer when only one of the two was ever meant to be part of the type's surface. ## What does *not* work You cannot embed the same type twice to get two copies: `struct { Grid; Grid }` and `struct { Grid; *Grid }` are both rejected outright, because both embedded fields would be named `Grid`, and a struct may not declare a duplicate field name. That is one of the few embedding errors reported at the declaration itself. Also note ambiguity is per name, not per type. Two embedded types that collide on `Draw` still promote every other name they do not share; only the colliding selector is unusable. ## Why the design is like this The depth rule makes shadowing predictable — you can always tell which one wins by counting levels, without knowing declaration order or the whole type graph — and refusing ties keeps the reader from having to know a precedence rule to understand a call. The cost is a compile error the language could have papered over; the benefit is that no Go call site silently means something other than what it appears to.