fix: mark List.length as @[implicit_reducible]#12924
Merged
Conversation
This PR fixes a regression introduced in Lean 4.29.0-rc2 where `simp` no longer simplifies inside type class instance arguments due to the `backward.isDefEq.respectTransparency` change. This breaks proofs where a term like `(a :: l).length` appears both in the main expression and inside implicit instance arguments (e.g., determining a `BitVec` width). After `simp only [List.length_cons]`, the main expression has `l.length + 1` but instances still have `(a :: l).length`, and `isDefEq` won't unfold `List.length` to reconcile them. Marking `List.length` as `@[implicit_reducible]` allows `isDefEq` to unfold it when checking implicit arguments, restoring the previous behavior. The root cause is that `GetElem` carries complex proof obligations in its type class instances, making the implicit arguments sensitive to definitional equality. We are considering a longer-term redesign with a noncomputable `GetElemV` variant based on `Nonempty` that avoids these casts entirely, but that is a larger change planned for a future release. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Collaborator
|
Reference manual CI status:
|
mathlib-nightly-testing bot
pushed a commit
to leanprover-community/batteries
that referenced
this pull request
Mar 15, 2026
mathlib-nightly-testing bot
pushed a commit
to leanprover-community/mathlib4-nightly-testing
that referenced
this pull request
Mar 15, 2026
|
Mathlib CI status (docs):
|
kim-em
added a commit
to leanprover-community/batteries
that referenced
this pull request
Mar 18, 2026
kim-em
added a commit
to leanprover-community/mathlib4-nightly-testing
that referenced
this pull request
Mar 18, 2026
|
Mathlib CI status (docs):
|
|
Mathlib CI status (docs):
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR fixes a regression introduced in Lean 4.29.0-rc2 where
simpno longer simplifies inside type class instance arguments due to thebackward.isDefEq.respectTransparencychange. This breaks proofs where a term like(a :: l).lengthappears both in the main expression and inside implicit instance arguments (e.g., determining aBitVecwidth).The problem: After
simp only [List.length_cons], the main expression hasl.length + 1but instances still have(a :: l).length. Sincesimpno longer simplifies inside instances, andisDefEqwon't unfoldList.lengthat the default transparency, subsequent lemma applications fail.Reproducer (from Son Ho, reported by Sebastian Ullrich):
The fix: Mark
List.lengthas@[implicit_reducible], allowingisDefEqto unfold it when checking implicit arguments. Several proofs that previously needed a trailingrflaftersimpnow close directly, sincesimpcan see throughList.lengthin more positions.Longer term: The root cause is that
GetElemcarries complex proof obligations in its type class instances, making implicit arguments sensitive to definitional equality of collection sizes. We are considering a redesign with a noncomputableGetElemVvariant based onNonemptythat avoids these casts entirely, but that is a larger change planned for a future release.