[Merged by Bors] - chore: replace haveI/letI with have/let in tactics when the goal is a prop#41708
[Merged by Bors] - chore: replace haveI/letI with have/let in tactics when the goal is a prop#41708thorimur wants to merge 2 commits into
haveI/letI with have/let in tactics when the goal is a prop#41708Conversation
PR summary e381f6e76dImport changes for modified filesNo significant changes to the import graph Import changes for all files
|
|
!bench |
|
Benchmark results for e381f6e against 8ccb214 are in. No significant results found. @thorimur
Medium changes (1🟥)
|
|
Thanks for making the PR! |
|
Thanks for the PR! Can you edit the PR description to say why this change was made? (You can copy from Anne's comment on the Zulip thread.) |
|
✌️ thorimur can now approve this pull request until 2026-07-28 10:14 UTC (in 2 weeks). To approve and merge, reply with
|
|
bors r+ |
…oal is a prop (#41708) Using `haveI`/`letI` for instances in proofs is a holdover from Lean 3, and is unnecessary in Lean 4. As explained by @Vierkantor on Zulip [here](https://leanprover.zulipchat.com/#narrow/channel/287929-mathlib4/topic/letI.2FhaveI.20linter/near/609781158): > Historical note: a lot of the `haveI`/`letI` usage is a remnant of Lean 3 times, where the `I` stood for Instances: the old versions of the `have`/`let` tactics would not add the new variable to the list of available instances, and you'd need `haveI`/`letI` to force an update to the instance cache and make them visible. In our modern Lean 4 age, basic `have`/`let` already make the instance available and `I` instead only stands for Inline. But the old `haveI` got ported to the new `haveI` and so there is a bit of a superstition that we have to keep using `haveI` and `letI` for instances. (Note that inlining can change IR for compiled defs, so we don't change those.) Try-this statements produced by #41657; applied mechanically by running `scripts/runSkimmer.sh`. Then, Mathlib.CategoryTheory.Galois.Basic was fixed up manually: it turned out that the `haveI`'s triggering the linter were completely unnecessary, which might be why universe issues came about when the linter suggested turning them into `have`s. Cleaning up term-mode `haveI`/`letI` is left for another PR. Co-authored-by: @JovanGerb
|
Pull request successfully merged into master. Build succeeded: |
haveI/letI with have/let in tactics when the goal is a prophaveI/letI with have/let in tactics when the goal is a prop
…oal is a prop (leanprover-community#41708) Using `haveI`/`letI` for instances in proofs is a holdover from Lean 3, and is unnecessary in Lean 4. As explained by @Vierkantor on Zulip [here](https://leanprover.zulipchat.com/#narrow/channel/287929-mathlib4/topic/letI.2FhaveI.20linter/near/609781158): > Historical note: a lot of the `haveI`/`letI` usage is a remnant of Lean 3 times, where the `I` stood for Instances: the old versions of the `have`/`let` tactics would not add the new variable to the list of available instances, and you'd need `haveI`/`letI` to force an update to the instance cache and make them visible. In our modern Lean 4 age, basic `have`/`let` already make the instance available and `I` instead only stands for Inline. But the old `haveI` got ported to the new `haveI` and so there is a bit of a superstition that we have to keep using `haveI` and `letI` for instances. (Note that inlining can change IR for compiled defs, so we don't change those.) Try-this statements produced by leanprover-community#41657; applied mechanically by running `scripts/runSkimmer.sh`. Then, Mathlib.CategoryTheory.Galois.Basic was fixed up manually: it turned out that the `haveI`'s triggering the linter were completely unnecessary, which might be why universe issues came about when the linter suggested turning them into `have`s. Cleaning up term-mode `haveI`/`letI` is left for another PR. Co-authored-by: @JovanGerb
Using
haveI/letIfor instances in proofs is a holdover from Lean 3, and is unnecessary in Lean 4. As explained by @Vierkantor on Zulip here:(Note that inlining can change IR for compiled defs, so we don't change those.)
Try-this statements produced by #41657; applied mechanically by running
scripts/runSkimmer.sh.Then, Mathlib.CategoryTheory.Galois.Basic was fixed up manually: it turned out that the
haveI's triggering the linter were completely unnecessary, which might be why universe issues came about when the linter suggested turning them intohaves.Cleaning up term-mode
haveI/letIis left for another PR.Co-authored-by: @JovanGerb