Lean 4

Type mismatch (Lean 4)

Q: How do I confirm the cause?

Hover over each part of the expected type in the editor to see hidden arguments and coercion arrows (↑). Restate the goal with show … to check that you and Lean agree on what is expected. Add set_option pp.all true in before the declaration to print every implicit argument and coercion.

Q: How do I fix "Type mismatch (Lean 4)"?

Compare the two types in the message line by line. Use #check on the lemma to see its exact statement, then give it the right arguments or flip an equation with .symm. For number-type differences use exact_mod_cast h, or push_cast / norm_cast first. In Mathlib, convert h leaves the differences as new goals so you can see exactly what does not match.

Q: How do I stop it happening again?

Annotate number literals and variables with their type, e.g. (2 : ℝ), so Lean does not default to ℕ. Pin your Mathlib version and expect renamed or restated lemmas when you update.

A term has a different type from the one Lean needs at that spot — for example a proof of one statement where another is required, or a ℕ where an ℤ is expected.

What it looks like

Main.lean:4:8: error: Type mismatch
  h
has type
  a < b
but is expected to have type
  a ≤ b

What does "Type mismatch (Lean 4)" mean?

The elaborator prints the term, the type it actually has and the type that was expected at that position. Since Lean 4.23 it starts with a capital T (Type mismatch); Lean 4.22 and earlier print type mismatch. When the two types look identical, the difference is hidden — implicit arguments, universe levels or coercions — and Lean tries to expose it by printing the differing parts with more detail.

What causes "Type mismatch (Lean 4)"?

The hypothesis or lemma you used proves a slightly different statement (sides swapped, < instead of ≤, another variable).
Numbers of different types: ℕ vs ℤ vs ℝ, which need a coercion such as (n : ℤ).
Implicit arguments were filled in differently than you meant, so the two types only look alike.
A lemma was renamed or its statement changed in a newer Mathlib.

How do I confirm the cause?

Hover over each part of the expected type in the editor to see hidden arguments and coercion arrows (↑).
Restate the goal with show … to check that you and Lean agree on what is expected.
Add set_option pp.all true in before the declaration to print every implicit argument and coercion.

How do I fix "Type mismatch (Lean 4)"?

Compare the two types in the message line by line.
Use #check on the lemma to see its exact statement, then give it the right arguments or flip an equation with .symm.
For number-type differences use exact_mod_cast h, or push_cast / norm_cast first.
In Mathlib, convert h leaves the differences as new goals so you can see exactly what does not match.

How do I stop it happening again?

Annotate number literals and variables with their type, e.g. (2 : ℝ), so Lean does not default to ℕ.
Pin your Mathlib version and expect renamed or restated lemmas when you update.

Got a different error? Paste it into the Explain This Error tool → Identifies the family and the fix — runs locally, nothing uploaded.