Method Sets
Fast recall
Quick revision
Core answer
Whether you understand Method Sets beyond memorized syntax.
Giving a definition without explaining a practical trade-off.
Connect the concept to a small production example and state its complexity or failure mode.
Interview-ready guide
Interview answer
A method set is exactly what satisfies an interface — the compiler checks 'does this value's type have every interface method?' and the method set is the answer for each type:
func (u User) Greet() string // in User's method set AND *User's
func (u *User) Inc() // in *User's method set ONLYThe rule with its consequence: *User's method set is a superset (both Greet and Inc); User's is Greet only. So *User satisfies any interface needing Greet or Inc; User satisfies only Greet-interfaces. The pointer can do everything the value can plus more.
Executed proof of the asymmetry: a pointer p := &u can call p.Greet() (value method on pointer — works, auto-dereference) AND p.Inc(); the bare value u can call u.Greet() but User{Name:"x"}.Inc() is a compile error — 'cannot call pointer method Inc on U' — because the method set of the VALUE doesn't include pointer-receiver methods.
Why the asymmetry exists: a pointer receiver means 'this method may modify the receiver' — which requires the method to have the receiver's address. A pointer has one; a bare value might not (temporaries, map elements — non-addressable storage). Rather than a silent auto-address in SOME contexts and not others, the rule is uniform: pointer-receiver methods live in the pointer's method set, period. The compiler's auto-addressing for addressable values (u.Inc() on a variable works — it's (&u).Inc()) is a CALL-SITE convenience, not a method-set change — and that distinction is exactly what trips the map-element case.
Method Sets
Direct Answer
The set of methods a TYPE has, determining interface satisfaction. For type T: methods with receiver T. For *T: methods with receiver T AND *T. The rule that decides whether your type satisfies an interface.
Deep Dive & Architecture
The method-set rule is arbitrary-looking until you trace the addressability reasoning, and the follow-up: WHY does u.Inc() compile when u is a variable, if Inc isn't in User's method set? Because the CALL rule and the METHOD SET rule are different rules:
Call rule: for an addressable value u, u.Inc() is shorthand for (&u).Inc() — the compiler takes the address, the method set of *User applies. For a NON-addressable value (map lookup result, function return, struct field of a non-addressable), the shorthand can't exist — no address exists — so the call is a compile error.
Method-set rule (interface satisfaction): does NOT apply call-site shorthands. An interface holding a User value has the User's method set — Greet, no Inc — regardless of where the value came from. This is why storing User values in an []Greeter works while []Incrementer rejects them: the method set is a property of the TYPE, frozen at the value's creation, not enhanced by the context of use.
The map-element proof that the two rules diverge: m[k].Inc() — m[k] is addressable-for-read but not writable-addressable (map internals move elements) — the call rule cannot apply its shorthand — compile error with the message 'cannot call pointer method on U' — the method set was never the issue; the address was.
The design coherence: Go wanted pointer receivers to be a real semantic statement (mutation capability) without making interfaces unpredictable. Method sets make interface satisfaction decidable from types alone; call shorthand keeps the ergonomics; addressability defines exactly where the shorthand may fire. Three rules, one coherent system — and interviewers probe exactly the seams (map elements, temporaries) where the rules must be applied separately.
Common Mistakes & Pitfalls
Giving a definition without explaining a practical trade-off.
Check your understanding
Answer these without looking back at the article.
- When would you use Method Sets in a real project?
- How would you compare Method Sets with an alternative?
- What is a common mistake when using Method Sets?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.