In Go, identifier visibility is determined by capitalization: 1) Exported identifiers start with a capital letter and are visible outside the package, forming the public API; 2) Unexported identifiers start with a lowercase letter and are accessible only within the same package; 3) Package-level scope allows exported identifiers to be accessed externally while unexported ones remain internal; 4) No keywords like public or private are used—visibility is purely lexical; 5) This design supports encapsulation, intentional API design, and controlled access to internal state, as seen in structs with mixed exported and unexported fields and associated methods that safely expose private data.

In Go, the visibility of identifiers—such as variables, functions, types, and methods—is determined by a simple naming convention based on the first letter of the identifier. This governs whether an identifier is exported (visible outside the package) or unexported (visible only within the same package).

Exported vs. Unexported Identifiers

Go uses capitalization to control visibility:

• Exported identifiers start with a capital letter (e.g., MyVar, DoSomething, Person).

  
  • These are visible to code in other packages.
  • They are part of the package's public API.

• Unexported identifiers start with a lowercase letter (e.g., myVar, doSomething, person).

  • These are only visible within the same package.
  • They are used for internal implementation details.

For example:

package counter

var counter int = 0        // unexported: only visible inside 'counter' package
var Counter int = 0        // exported: visible to other packages

func increment() {         // unexported function
    counter  
}

func Increment() {         // exported function
    increment()
}

In another package:

package main

import "counter"

func main() {
    counter.Increment()  // OK: Increment is exported
    // counter.counter    // Compile error: counter is unexported
    // counter.increment() // Compile error: increment is unexported
}

Scope Rules Summary

• Package-level scope: Only identifiers starting with a capital letter can be accessed from outside the package.
• Internal scope: Unexported identifiers are accessible throughout the same package, across multiple .go files.
• No access modifiers: Unlike languages such as Java or C#, Go doesn’t use keywords like public, private, or protected. Visibility is purely lexical.

Key Implications

• Encapsulation: Use unexported identifiers to hide implementation details and prevent external dependencies on internal logic.
• API design: Carefully choose which types, functions, and variables to export—once exported, changing them can break compatibility.
• Testing: You can test unexported functions by placing test files in the same package (e.g., package counter instead of package counter_test if using a separate package for tests).

Examples in Practice

type Person struct {
    Name string // exported field
    age  int    // unexported field
}

func NewPerson(name string, age int) *Person {
    return &Person{
        Name: name,
        age:  age,
    }
}

Here, Name can be accessed directly from outside the package, but age cannot. Instead, you might provide a method:

func (p *Person) Age() int {
    return p.age  // safe access to unexported field
}

This allows controlled access while keeping internal state encapsulated.

Basically, Go’s visibility rules are simple but powerful: uppercase = public, lowercase = private, all at the package level. No extra keywords, just consistent naming.

The above is the detailed content of What are Go's visibility rules for identifiers (exported vs. unexported)?. For more information, please follow other related articles on the PHP Chinese website!