Can code in one file of a Go package read an unexported field of a struct declared in another file of that package?

## The boundary is the package Go draws exactly one encapsulation line, and it is around the package. An unexported identifier is visible to every declaration in every file of the package that declares it, and to nothing else. That differs from the model most engineers arrive with. In a class-based language, `private` usually means "visible to this class", so two classes in the same file or the same namespace still cannot reach into each other. In Go, two types declared in the same package can read and write each other's lower-case fields freely. ```go // file: user/user.go type User struct { id int64 email string } // file: user/store.go type store struct { byID map[int64]*User } func (s *store) put(u *User) { s.byID[u.id] = u // legal: same package, different file, different type } ``` Both files declare `package user`, so they compile into one package scope. `store.put` names `u.id` with no ceremony. ## What follows from that **Files are an organising tool, not a security tool.** Moving a type's methods into a second file, or splitting a large file in half, changes nothing about who can touch what. If a review comment says "move this into its own file so nothing else uses it", the comment is mistaken; the change to make is a new package. **Accessors do not protect within a package.** A `func (u *User) Email() string` method is useful for importers, who cannot see `u.email` at all. For code in the same package it is a convenience at best: the neighbouring function can assign `u.email` directly and skip whatever the setter would have validated. If an invariant must hold, it holds because the package's own code is small enough to read and review, not because the compiler enforces it internally. **Nesting confers nothing.** A common wrong model is that `user/internal-ish-subdir` or `user/store` is "inside" `user` and therefore privileged. Go has no such relationship. Every directory is an independent package, and `user/store` sees only the *exported* names of `user`, exactly as an unrelated repository would. **Package size is a design decision, not a filing decision.** Because package scope is the only scope you get, the size of your package is the size of your trust boundary. A 40-file package where everything reaches into everything is a package that has given up on encapsulation; the fix is to carve out a smaller package whose exported surface states what the rest of the code is allowed to do. This is the main reason Go codebases end up with many small, sharply named packages rather than a handful of large ones. **Test code in the same package sees everything.** A test file declaring `package user` is part of the package and can reach unexported names, which is how Go supports white-box tests without any special mechanism. That is a property of the same rule, not an exception to it. ## Diagnosing it When you are trying to work out what is really encapsulated, `go doc <package>` shows only what leaves the package, and `go doc -u <package>` shows the rest. If the second list is where all the interesting behaviour lives and the package is enormous, the encapsulation is nominal. ## Misconceptions to avoid - "Each file has its own scope." It does not; only *imports* are file-scoped in Go, which is a separate rule about import names. - "Unexported means private to the type." There is no per-type privacy level in the language. - "A subpackage can see its parent's internals." It cannot; there is no parent-child visibility relationship between directories.