Reach proof elaboration breaks across Lean toolchain compatibility boundary

Question

Reach exposes its proof interfaces as Lean 4 library code backed by elaborators and tactics, so each release is pinned to a specific Lean toolchain. When a project upgrades its Lean toolchain but keeps the same Reach checkout—or updates Reach without moving the pinned toolchain—previously working tactic-based proofs can fail to elaborate. The tactic and helper lemma layer is the most version-sensitive part of this boundary, and documented examples from older releases may reference names or behaviors that have shifted.

The open question is how aggressively Reach tracks new Lean 4 releases versus remaining on a stable pin. Because the project has not documented a fixed cadence for toolchain adoption, downstream users cannot assume that a proof compiling under one pairing will compile unchanged after upgrading either side independently.

What is the documented compatibility contract between a Reach release and its pinned Lean toolchain when only one component is upgraded? Should users expect tactic-based proofs to survive a Lean toolchain bump without corresponding Reach changes, or is the boundary treated as a hard break requiring coordinated upgrades? How can teams determine which Reach version pairs with a given Lean release before committing to an upgrade?

Tasadduq Burney · Answer

Answer to the Question
The official Reach contract states that each release is tied to a single, pinned Lean 4 toolchain. Only that toolchain is guaranteed to compile the tactic‑based proofs shipped with that Reach version.
What to Expect When Upgrading

Upgrading Lean 4 alone – without a matching Reach release – will almost always break tactic‑based proofs, because the Lean compiler, core libraries, and tactic engine can change between releases.
Upgrading Reach alone – while staying on the same Lean toolchain – is safe; Reach’s own code and lemma libraries are updated to work with the pinned Lean version.
Both upgrades together, in the order that the new Reach release lists its pinned Lean version, preserve proof integrity.

How to Verify the Current Pairing

Run lean --version in the project root.
Open the .lean-toolchain file in the checked‑out Reach source tree. The file contains a single line with the exact Lean version that Reach expects.
Compare the two strings. If they match, the pairing is correct.
As a sanity check, compile a minimal Reach file that uses a tactic (e.g. simp or apply) and confirm that it elaborates without error.

Determining the Right Reach Version for a Lean Release
Reach release notes include a “Toolchain” section that lists the pinned Lean version. If you need to use a newer Lean release, you must wait for a Reach tag that pins that version. Until then, either downgrade Lean or hold off on the upgrade.
Next Step: Identify Your Current Environment
To give a precise recommendation, I need to know:

The exact Lean 4 version you are currently using (output of lean --version).
The Reach release (Git tag or commit) you have checked out.

Once those are known, I can tell you whether a coordinated upgrade is required or if you can safely bump only one side.
Example Compatibility Matrix

Reach TagPinned Lean Version

v0.8.1leanprover/lean4:4.0.0
v0.9.0leanprover/lean4:4.1.0

Reach proof elaboration breaks across Lean toolchain compatibility boundary

1 answer

Answer to the Question

What to Expect When Upgrading

How to Verify the Current Pairing

Determining the Right Reach Version for a Lean Release

Next Step: Identify Your Current Environment

Example Compatibility Matrix

Your perspective belongs here.

0 question comments

Reach Tag	Pinned Lean Version
v0.8.1	leanprover/lean4:4.0.0
v0.9.0	leanprover/lean4:4.1.0