Promotion and Shadowing

## What an anonymous field is A Go struct field is normally written as `name Type`. If you write only the type, the field is *embedded* and is called an anonymous field: ```go type Grid struct { Rows, Cols int } func (g Grid) Draw() { /* paint cells */ } type Dashboard struct { Grid // embedded: an anonymous field Title string // an ordinary named field } ``` `Dashboard` has two fields. The second is `Title`. The first is not nameless — it takes the *unqualified type name* as its implicit field name, so it is called `Grid`. That naming rule is worth memorising because it also decides the name for qualified and pointer types: embedding `bytes.Buffer` gives a field named `Buffer`, and embedding `*Grid` gives a field named `Grid`. ## What promotion actually does Because the field exists, `d.Grid.Rows` is an ordinary selector chain. Promotion is the rule that lets you write the shorter form when there is no ambiguity: ```go var d Dashboard d.Rows = 24 // same storage as d.Grid.Rows d.Draw() // same call as d.Grid.Draw() d.Title = "cpu" // an ordinary field, no promotion involved ``` Both *fields* and *methods* are promoted. A promoted method is not a wrapper the compiler generates around a copy; the receiver of `Draw` is the embedded `Grid` value living inside `d`, so a pointer-receiver method promoted from an embedded value mutates the real inner field, not a copy. Promoted methods also become part of the outer type's method set. That is why embedding is Go's usual way to acquire an interface implementation without writing one: a struct that embeds a type already implementing `io.Reader` satisfies `io.Reader` itself. ## The embedded field is still a value you can use Because the embedded field is a real field with a real name, all of these are legal and mean what they say: ```go d.Grid = Grid{Rows: 24, Cols: 80} // assign the whole embedded value render(d.Grid) // pass it where a Grid is wanted d2 := Dashboard{Grid: Grid{Rows: 24}, Title: "cpu"} ``` Note the composite literal: you must use the type name as the key. There is no way to set an embedded field positionally-by-inner-field; `Dashboard{Rows: 24}` does not compile, because `Rows` is not a field of `Dashboard` for the purposes of a literal even though the selector `d.Rows` works. ## Export rules are unchanged Promotion does not launder visibility. Unexported fields and methods of the embedded type are promoted, but an unexported name is still only usable inside the package that declared it. If your package embeds a type from another package, you gain shortcut access to exactly the exported names you could already reach through the field. Conversely, embedding an *unexported* type in an *exported* struct still promotes that type's exported methods to importers, which is a common way to give callers a method set without giving them the type. ## Where the shortcut stops Promotion reaches through as many levels of embedding as you have, choosing the shallowest match. It stops in three places worth knowing early: - **Composite literals**, as above: keys are the outer type's own field names, including the embedded type name. - **Ambiguity**: if two embedded types at the same depth both offer the name, the short selector is not allowed and you must say which one you meant. - **Shadowing**: a field or method declared directly on the outer struct wins over a promoted one of the same name, silently. ## It is composition, not a class hierarchy The mental model that survives contact with Go is: *the outer struct contains a value, and the compiler saves you some typing when you reach into it.* No subtype relationship is created. A `Dashboard` is not assignable to a `Grid` parameter — you pass `d.Grid`. A function that takes a `Grid` cannot be handed a `Dashboard`. Everything promotion gives you is a shorter spelling of a selector plus membership in the outer type's method set, and knowing that one sentence answers most follow-up questions about it.