When may a Go method declaration leave the receiver unnamed, and why would you?

## Receivers, like parameters, may be nameless Go requires a receiver's **type** in a method declaration, not its **name**. All three of these are valid, and they compile to the same thing: ```go func (m Meters) Unit() string { return "m" } func (_ Meters) Unit() string { return "m" } func (Meters) Unit() string { return "m" } ``` The first names the receiver and never uses it. The second names it explicitly blank. The third omits the name entirely. Go allows the same thing for ordinary parameters — `func handle(_ int, s string)` — because a signature sometimes has to accept a value it does not want. ## When to reach for it The honest test is whether the body reads the receiver. If it does not, the name is noise, and worse, it is a small lie: it suggests the method's result depends on the value when it does not. Typical cases in a value package: - **Constant answers about the type.** A unit string, a dimension name, a scale factor — every `Meters` returns `"m"`, so the particular `Meters` is irrelevant. - **Methods that exist to make a type satisfy an interface** where the implementation needs no state. - **Methods that only inspect their arguments**, using the receiver purely for dispatch. In each case the unnamed receiver is documentation that cannot go stale: a reader knows from the first line that this method's answer is a property of the type, not of the value. ## The secondary benefit: nothing to shadow A named receiver occupies an identifier inside the body's scope, and that identifier hides anything of the same name from the enclosing scope — an imported package, a package-level variable. A receiver you do not name cannot shadow anything, which is a small extra reason not to invent a name you will not use. ## When not to use it Do not leave a receiver unnamed because you cannot decide what to call it, and do not leave it unnamed in a method that would use it after one more line of work. If a later change needs the value, you add the name then — a one-character diff — but a reviewer reading the intermediate state was told something untrue. There is also nothing to be consistent with here in the way there is for names. A type whose twenty-nine methods use `p` and whose thirtieth omits the receiver is not inconsistent: the thirtieth has no receiver name to disagree about. The convention that every method on a type shares one receiver name applies to the methods that actually name one. ## Named blank versus omitted Both `(_ Meters)` and `(Meters)` are idiomatic and mean the same thing to the compiler. The bare-type form is the more common in Go code and reads slightly cleaner; the explicit `_` is sometimes preferred in a file where other declarations use `_` for the same purpose, so the intent is spelled out rather than inferred from an absence. Pick one and keep the package uniform. ## What it is not An unnamed receiver changes nothing about how the method is called, what type it belongs to, or whether it is exported — that is decided by the method's own name, its capitalisation, and its receiver type. It is purely a statement about the body: this method ignores the value it was called on.