In Go, can you declare methods on a non-struct type such as type Money int64?

## Methods are not a struct feature Engineers arriving from class-based languages expect methods to require something class-shaped. In Go a method is attached to a **defined type**, and any defined type will do: ```go type Money int64 // amounts in minor units, e.g. cents type Statuses []string type Handler func(string) error type Index map[string]int64 ``` Each of these can carry methods. This is how a domain concept that is 'really just a number' still gets behaviour — validation, formatting, arithmetic that respects the unit — without wrapping it in a one-field struct. ## The two rules **The receiver base type must be defined in the same package as the method.** You cannot write `func (d time.Duration) Half() time.Duration` in your own package, and you cannot write methods on the predeclared `int`. What you do instead is declare your own type: `type Timeout time.Duration`, then give `Timeout` methods. Note that a defined type declared this way starts with an empty method set of its own — it does **not** inherit methods from the type it was defined from, so `Timeout` gets none of `time.Duration`'s. That is the price of the wrapper, and it is deliberate: the new type is a new type, not a subtype. **The receiver base type must not be a pointer type or an interface type.** `type P *Order` cannot receive methods, and neither can an interface type — the whole point of an interface is that its method set is declared, not implemented. ## Everything about receivers carries over The value-versus-pointer rule is identical for a defined integer type: ```go func (m Money) Add(n Money) { m += n } // writes to the copy; lost func (m *Money) Add(n Money) { *m += n } // writes through; visible ``` With a non-struct base type the pointer form needs an explicit dereference — `*m += n` — because there is no field selector doing it implicitly, and that visual difference is a useful reminder of what the pointer receiver is actually doing in the struct case too. Most defined-scalar types end up with value receivers, and that is usually right: they are small, they are conceptually values, and the operations you want are 'produce a new amount' rather than 'edit this amount in place'. `func (m Money) Plus(n Money) Money { return m + n }` is more idiomatic than an in-place `Add`. ## Why it is worth doing The payoff is that the compiler starts enforcing your unit. If `TotalMinor` is an `int64`, nothing stops a caller adding a value that was actually in major units, or in another currency. If it is a `Money`, an accidental `int64` mixes in only with an explicit conversion, which is exactly the moment a reviewer wants to see. Attaching `String() string` to the type gives it a printed form everywhere `fmt` formats it, so the unit shows up in logs without every call site remembering to divide by a hundred. The cost is friction at boundaries — JSON decoding, database scanning and arithmetic with plain integers all need conversions or extra methods — so this is a judgment call per type, not a blanket rule. A good middle ground is to define the type where the unit is genuinely error-prone (money, durations you did not get from `time`, identifiers of different entities that are all integers) and leave general-purpose counters alone. ## A note on generic types A defined generic type carries its type parameters in the receiver: `func (s *Stack[T]) Push(v T)`. That has been the shape since generics arrived. Separately, Go 1.27 allows a *method* to declare its own type parameters; such a generic method cannot implement an interface method, so it is a tool for helper methods rather than for widening an abstraction.