In Go, what makes an identifier visible outside its package, and what does an unexported struct field mean for importing packages?

## The rule Go spells access control with capitalisation. An identifier is **exported** — visible to any package that imports the declaring package — if and only if its name begins with an upper-case Unicode letter. Everything else is visible only inside the package that declares it. There is no `public`, `private`, `protected`, `friend`, `module` or `sealed` keyword; there is one rule and no modifiers on it. The rule applies to every named thing: - top-level `const`, `var`, `type` and `func` declarations, - **struct fields**, - **methods**, - methods listed inside an interface type. So `Runner` is exported, `runner` is not; `Runner.Applied` is exported, `Runner.applied` is not; and a package can perfectly well export a type whose fields are all unexported. ## The unit of privacy is the package, not the file or the type This surprises people arriving from Java or C#. A Go package is usually a directory of several `.go` files, and all of them share one scope. If `parse.go` declares `type sqlFile struct{...}`, then `run.go` in the same package uses it without ceremony. There is no file-private level, and no per-type privacy either: a lower-case field of one struct is readable by any other code in the same package, including a different type's methods. Privacy in Go is a boundary you draw around a *directory*, not around a class. ## What an unexported field actually forbids Suppose a schema-migration package declares: ```go package migrate type Runner struct { dir string applied int } ``` From another package you can name the type `migrate.Runner`, declare variables of it, pass it around, and store it in a slice. What you cannot do is: - read or assign `r.dir` — the compiler reports that `r.dir` is undefined and refers to an unexported field; - build one with a keyed composite literal `migrate.Runner{dir: "./sql"}` — `unknown field dir`; - build one with a positional literal `migrate.Runner{"./sql", 0}` either, since that would have to supply the unexported fields; - set the field through reflection: a reflected value obtained from an unexported field reports that it cannot be set, and assigning to it panics. What is left is exactly what the package chose to expose: exported methods, and any exported constructor. That is the point. The zero `migrate.Runner{}` may be useless — no directory, nothing to apply — so the package supplies `func New(dir string) *Runner` and documents it as the way in. Callers cannot construct a half-built value even by accident, because the parts they would have to fill in are not visible to them. ## Why this matters for surface size Every upper-case letter in your package is a promise. Someone else's code will compile against that name, and from then on the name, its shape and its behaviour are yours to keep working. Lower-case costs you nothing: you can rename a field, change its type, split it into three, or delete it, and no build outside your package notices. So the default is lower-case, and raising a letter is a deliberate decision with a caller behind it. A practical habit follows: write the whole package unexported first, then export only the identifiers your own example or test actually needs from outside. A helper type that exists so two of your functions can share a parse result should never be exported; a struct field that exists to cache a computed value should never be exported. ## Consequences worth knowing early - **Documentation follows the rule.** `go doc` shows exported identifiers by default, so the exported set is literally the documented API of your package. - **Tests inside the package see everything.** A test file declared as `package migrate` can touch unexported identifiers; one declared `package migrate_test` in the same directory sees only the exported surface, which is a useful way to feel how big that surface is. - **Some libraries do care about case.** Packages that inspect your structs through reflection can only see exported fields, which is why an unexported field is skipped when a struct is encoded, and why struct types meant to be serialised carry exported field names. The rule is small enough to state in one sentence, and most of Go's package-design advice is downstream of it: keep the letters low, and you keep your options open.