Lean 4

Application type mismatch (Lean 4)

Q: How do I confirm the cause?

Find the argument Lean names and compare its type with the matching parameter in the #check output. Look for a missing or extra argument earlier in the call: everything after it shifts by one. If the message starts with (kernel), the elaborator accepted the term but Lean's kernel rejected it — usually a bug in a tactic or a definition using unsafe features, worth reporting with a minimal example.

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

Run #check on the function to see its parameters in order, including the implicit ones in braces. Pass arguments by name to avoid ordering mistakes: foo (h := hx). Write @foo to supply every argument explicitly when implicit arguments get in the way. If only the number type differs, add the cast or use exact_mod_cast.

Q: How do I stop it happening again?

Use named arguments for lemmas with many parameters. Keep hypotheses in the form lemmas expect (a a), restating them with have when needed.

You passed an argument of the wrong type to a function or lemma — Lean names the argument, its type and the type the function wanted.

What it looks like

Main.lean:6:9: error: Application type mismatch: The argument
  hba
has type
  b < a
but is expected to have type
  a < b
in the application
  le_of_lt hba

What does "Application type mismatch (Lean 4)" mean?

It is raised when an argument does not fit the parameter it is passed to. The wording has changed twice: Lean 4.23 and later print Application type mismatch: The argument … has type … but is expected to have type … in the application …; Lean 4.21 and 4.22 print Application type mismatch: In the application … the argument …; Lean 4.20 and earlier print application type mismatch, the application, then argument … has type ….

What causes "Application type mismatch (Lean 4)"?

Arguments in the wrong order, or one too many or too few before this one.
A hypothesis about different terms than the lemma expects (h : b < a given where a < b is needed).
An argument given explicitly where the lemma takes it implicitly, which shifts the others along.
The number types differ, e.g. a fact about ℕ passed to a lemma about ℝ.

How do I confirm the cause?

Find the argument Lean names and compare its type with the matching parameter in the #check output.
Look for a missing or extra argument earlier in the call: everything after it shifts by one.
If the message starts with (kernel), the elaborator accepted the term but Lean's kernel rejected it — usually a bug in a tactic or a definition using unsafe features, worth reporting with a minimal example.

How do I fix "Application type mismatch (Lean 4)"?

Run #check on the function to see its parameters in order, including the implicit ones in braces.
Pass arguments by name to avoid ordering mistakes: foo (h := hx).
Write @foo to supply every argument explicitly when implicit arguments get in the way.
If only the number type differs, add the cast or use exact_mod_cast.

How do I stop it happening again?

Use named arguments for lemmas with many parameters.
Keep hypotheses in the form lemmas expect (a < b rather than b > a), restating them with have when needed.

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