Inconvenient equational lemmas for `if x then match n with ... else 0`

Prerequisites

• Check that your issue is not already filed:
  https://github.com/leanprover/lean4/issues
• Reduce the issue to a minimal, self-contained, reproducible test case.
  Avoid dependencies to Mathlib or Batteries.
• Test your test case against the latest nightly release, for example on
  https://live.lean-lang.org/#project=lean-nightly
  (You can also use the settings there to switch to “Lean nightly”)

Description

Consider the following example:

module

opaque x : Bool

def f (n : Nat) : Nat :=
  if x then
    match n with
    | 0 => 2
    | n' + 1 => 1
  else
    0

example (h : x = false) : f n = 0 := by
  -- rw [f, if_neg (by grind)] -- failed to rewrite using equation theorems
  rw [f.eq_def, if_neg (by grind)]

/-- info: f.eq_1 : f 0 = if x = true then 2 else 0 -/
#guard_msgs in
#check f.eq_1
/-- info: f.eq_2 (n' : Nat) : f n'.succ = if x = true then 1 else 0 -/
#guard_msgs in
#check f.eq_2

The generated equational theorems are inconvenient when knowing x = false because they require either n = 0 or n = _ + 1, even though n is irrelevant for this case.

Expected behavior: [Clear and concise description of what you expect to happen]

I would have expected that the equation compiler does not look inside if branches to find out whether the function branches over n. As a result, I would have expected only one equational theorem eq_1 that is identical to eq_def.

Summa summarum, I would have expected rw [f] to work.

Actual behavior: [Clear and concise description of what actually happens]

There are only two equations for different values of n. Therefore, we can't unfold f before knowing whether n is zero, even though n is completely irrelevant for the negative if branch.

Versions

Lean 4.30.0-nightly-2026-03-01
Target: x86_64-unknown-linux-gnu

Impact

Add 👍 to issues you consider important. If others are impacted by this issue, please ask them to add 👍 to it.

Start with the minimal reproducer in the issue and run it against the cited Lean nightly version. Investigate the equation compiler behavior for the if containing a match, then verify that the generated equations no longer split on n and that rw [f] works for the shown hypothesis.