A method calls a mutating member on a struct returned from a property, but the expected state does not change. What could be happening?

Why mutable structs and defensive copies are surprising

Diagnoses lost struct mutations and explains how readonly access can trigger defensive copies.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

A struct is a value, so reading it from a property normally returns a copy. Mutating that copy does not update the struct stored inside the owning object. Readonly fields and in parameters can also cause the compiler to make a defensive copy before calling a member that might mutate the receiver. I would first identify which storage location owns the real value, then avoid mutating a temporary copy. The clearest fix is often to make the struct readonly and return a new value for each change.

Full answer below

Practice focus

Struct copy semantics, property returns, readonly receivers, defensive copies, readonly struct design, and API predictability.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
A struct can look like a small object while silently being copied at assignments, returns, and readonly boundaries. Mutation against the wrong copy is a correctness bug that can be difficult to see in review.
A struct is a value, so reading it from a property normally returns a copy. Mutating that copy does not update the struct stored inside the owning object. Readonly fields and in parameters can also cause the compiler to make a defensive copy before calling a member that might mutate the receiver. I would first identify which storage location owns the real value, then avoid mutating a temporary copy. The clearest fix is often to make the struct readonly and return a new value for each change.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
For example, if order.Total returns a mutable struct, calling a mutating method on the returned value may only change a temporary. An explicit read-modify-write can work: copy the value, create or mutate the new value, then assign it back through a setter. A better value-object design is with methods such as returning a new . That aligns the API with value semantics and makes copies harmless rather than surprising. It also gives callers one obvious new value to assign, compare, or pass onward.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Calling a mutating method on a struct value returned by a property and expecting stored state to change.
Making a struct mutable because its members resemble a class API.
Using a large struct widely without measuring copy cost.
Assuming in always prevents every copy regardless of member declarations.

A method calls a mutating member on a struct returned from a property, but the expected state does not change. What could be happening?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section

Skill areas

Suggest an improvement