compare Value Vs Pointer Receivers with an alternative
Fast recall
Quick revision
Core answer
Practical understanding of Value Vs Pointer Receivers.
Repeating a definition without saying when to use it.
Give one trade-off and say how you would test it.
Interview-ready guide
Interview answer
Legal, discouraged, and the reason is the split method set:
type Counter struct{ n int }
func (c Counter) Get() int { return c.n } // value
func (c *Counter) Inc() { c.n++ } // pointerNow the sets: Counter{Get}; *Counter{Get, Inc}. An interface{Get()} takes both; interface{Inc()} takes only *Counter; interface{Get() Inc()} takes only *Counter — a value Counter can never satisfy the full one.
That split is the maintenance hazard: each new interface that mixes the type's methods silently selects which receiver form works — users discover via compile errors, each interface a fresh surprise. The type 'meant to be' a value OR a reference stops being either; it's whatever each interface admits.
The convention that prevents it: the FIRST pointer-receiver method (needed for mutation, or size, or mutex) converts the whole type — all methods become pointer receivers. The cost of the rule (value methods that didn't need the pointer pay indirection) is far below the cost of the split (per-interface satisfaction roulette + readers tracking per-method receiver kinds).
The exceptions the ecosystem accepts: small value-semantics types with ONE odd method (e.g. a Copy() that takes a value receiver for the return). And the standard library exhibit of the uniform rule: time.Time — every method value receiver (immutable value semantics); bytes.Buffer — every method pointer (mutable reference semantics). Each type is one thing, and its receivers announce which.
The interview phrasing that lands: mixing doesn't break compilation — it breaks predictability. The receiver kind is the type's value-vs-reference identity; a mixed type has two identities, and every interface picks one at random.
compare Value Vs Pointer Receivers with an alternative
Direct Answer
Yes — it compiles. But the method set splits (interface satisfaction differs by which receivers your methods use), and consistency is the strong convention: all value or all pointer once the type needs one pointer method.
Deep Dive & Architecture
The method-set split, followed to its compile-time consequence: an interface that mixes methods from both receiver kinds — interface { Get() Inc() } — can only be satisfied by *Counter. The value Counter satisfies Get()-only interfaces, so every place the type is USED chooses a receiver form: the API surface forks per interface. Callers hold Counter where value suffices, *Counter where both are needed — two shapes of the same type in one codebase, decided interface by interface.
What consistency buys: one receiver kind means one method set means one interface story. *Counter everywhere: every satisfiable interface is satisfied — by the pointer, uniformly. The uniform type is legible: readers never ask which form satisfies what — the answer is always the pointer.
The escape hatches that keep the rule honest: types that are genuinely values (small, immutable — time.Time) keep ALL value receivers — consistency costs nothing. Types that need one pointer method convert once, wholesale — the conversion is mechanical (add the star to every receiver), the behavior change is none (value methods on pointers work — the superset rule), and the only observable difference is interface satisfaction, which becomes BETTER. The refactor is safe in one direction — value-to-pointer — and the ecosystem convention reflects that asymmetry.
Common Mistakes & Pitfalls
Repeating a definition without saying when to use it.
Check your understanding
Answer these without looking back at the article.
- What is Value Vs Pointer Receivers, and when would you use it?
- When would you use Value Vs Pointer Receivers in a real project?
- What is a common mistake when using Value Vs Pointer Receivers?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.