In MockK, what happens when one argument of a stubbed call is a matcher such as any() and another is a plain literal like 42? When does that combination break, and why does wrapping the literal in eq() fix it?

## What actually happens with a mixed call When you write `every { repo.find(any(), 42) } returns row`, MockK executes the lambda under a call recorder. `any()` registers a matcher and returns a generated *signature value* of the parameter type; `42` is just the number 42. When the mocked method is invoked, MockK holds the argument list `[<signature value>, 42]` and the matcher list `[any()]`, and reconciles them: arguments that are recognisably generated signature values mark matcher positions; every other argument is wrapped as an implicit `eq(...)`. The recorded stub is effectively `find(any(), eq(42))`. So the honest answer to "can you mix matchers and constants in MockK?" is **usually yes** — the binding is positional-by-value, not a rule that forbids mixing. ## Where the model runs out of room The inference depends on the generated signature value being distinguishable from anything you might legitimately pass: - **Tiny value spaces.** A `Boolean` parameter has two possible values. There is no dummy that cannot also be a real literal, so a call mixing a matcher with a boolean literal — or with several booleans — is prone to ambiguous binding. The same pressure exists for very small enums and, less often, for tiny numeric literals. - **Collisions.** If the literal you pass happens to equal the generated value for a matcher of the same type, MockK cannot tell which position was the matcher. - **Values you carry around.** Reusing a matcher's returned value elsewhere in the block, or passing the same instance to two parameters, feeds the reconciliation values it cannot interpret. The visible symptoms are the exception `io.mockk.MockKException: Failed matching mocking signature for ...` followed by `left matchers: [any()]` — MockK telling you which matchers it could not place — or, more insidiously, a stub that records successfully but with the matcher attached to the wrong parameter, so the stub never matches at call time and you debug a `no answer found for: ...` (strict mock) or an unexpected relaxed default instead. ## Why eq() is the fix `eq(42)` is a real matcher: it registers with the recorder and returns its own signature value. If every argument is a matcher, the matcher count equals the argument count and each position is accounted for — there is nothing left to infer, and the tiny-value-space problem disappears because the boolean argument is now itself a matcher slot rather than a literal MockK must recognise. That is where the rule of thumb comes from: **all matchers or all literals, never a mix**. It is not that MockK forbids mixing; it is that all-matchers is the form with no inference in it, so it never fails for reasons unrelated to your test. ## The related trap: what implicit eq() means An implicit or explicit `eq(x)` matches with `equals()`, not identity. For Kotlin data classes that is structural equality, which is usually what you want; for a class that does not override `equals()` it degrades to reference equality, and a stub written with a freshly constructed argument silently never matches. When a mixed call misbehaves, check both things: is the matcher bound to the position you meant, and does the literal's type actually implement value equality? If it does not, `refEq(...)` or `match { }` expresses the intent explicitly. ## How to talk about it A strong answer separates the *rule of thumb* from the *mechanism*. The rule of thumb — wrap constants in `eq()` so a call is all matchers — is what you follow every day and what makes reviews easy. The mechanism — signature-value binding with implicit `eq()` for the rest — is what lets you explain why a mixed call worked fine in ten tests and blew up in the eleventh with `left matchers: [any()]`, and why the eleventh one had a `Boolean` parameter. Candidates who state "MockK forbids mixing matchers and constants" are repeating a rule imported from other mocking libraries and cannot explain any of the observed behaviour.