In a Go struct, what does capitalising a field name like Name instead of name control?

## The rule Go does not have access modifiers. There is no `public`, `private`, `protected` or `internal` keyword anywhere in the language. Instead, **one rule covers every identifier**: if the first character of the name is an upper-case letter, the identifier is *exported*; otherwise it is *unexported*. That applies to package-level functions, types, constants and variables — and, exactly the same way, to the fields and methods of a struct. ```go type Schema struct { Name string // exported id int // unexported } ``` Any package that imports this one can write `s.Name`. Writing `s.id` from outside the package is a compile error: the selector simply does not resolve there. ## The unit of privacy is the package This is the part that trips up people arriving from Java, C# or C++, where privacy is per class. In Go the unit is the **package**, which may be many files in one directory. Every file compiled into that package sees the same identifiers, so a helper in another file of the same package can read and assign `id` freely. There is no way to hide a field from other code in its own package, and no notion of a field being private to the struct itself. A practical consequence appears in tests. A test file declared `package schema` is part of the package and may assert on unexported fields; a test file declared `package schema_test` is a separate package and may not — it sees only the exported surface, which is exactly the point of writing tests that way when you want to exercise the public API. ## What being unexported does *not* mean An unexported field is not removed, hidden at run time, or excluded from the value: - It occupies its position in the struct's memory layout and contributes to the struct's size and alignment. - It is copied along with everything else when the struct is assigned, passed to a function, returned, or stored in a slice. - It participates in equality when the struct is compared, even from a package that cannot name it. What it loses is *nameability from outside*. Code in another package cannot select it, and generic library code that inspects types at run time can read type information about it but cannot set it. That is why data-driven libraries in Go universally require exported fields for anything they must populate. ## Choosing what to export Exporting a field is a bigger commitment than exporting a method. It publishes the field's **name** and its **type**, and it lets callers assign to it without going through any validation you wrote. Once other packages depend on `cfg.Retries`, you cannot rename it, change its type, or start deriving it from something else without breaking them. The usual patterns: - **Plain data carriers** — a request or a row of a report — export their fields. There is no invariant to protect, and callers need to build the value with a composite literal. - **Types with invariants** — a connection, a counter, a validated identifier — keep the state unexported and expose a constructor such as `NewClient(...)` plus methods. Callers cannot put the value into an inconsistent state because they cannot reach the state. When you do want read-only access, add an accessor. Go convention omits the `Get` prefix, so the method reading `name` is written `func (s Schema) Name() string`. A field and a method cannot share a name on the same type, which is why the field is usually the lower-case one. Be aware that returning a slice, map or pointer field from an accessor hands the caller a reference into your value — copy it if the invariant matters. ## Common mistakes - Assuming the rule is per file. It is per package. - Assuming an unexported field is dropped from the struct, or that its bytes are somehow protected. It is ordinary memory; only the compiler's name resolution enforces the boundary. - Trying to export just for one caller. That is a permanent widening of the API; a method or a constructor argument is usually the smaller change. - Forgetting that a package's own tests, benchmarks and examples in the same package can reach everything, so a green in-package test proves nothing about what an importer can actually do.