leanprover / leanprover/lean4

RFC: have tactic should emit warning on data

Open
#3,559 8 comments 23 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

P-medium RFC
Dominant language
Lean
Stars
9.2k
Forks
990
Avg merge
1d 17h
Merged PRs (30d)
175

Description

Explanation

The have tactic is an enormous footgun for new users, since if you write have : <some type> := ... (i.e. not a proposition but data), then the value of the data is forgotten. This is especially problematic if the type is a class, since it can then be used without the user realizing.

Typical example:

example (n m : Nat) : True := by
  have h1 : n + m = m + n := Nat.add_comm n m
  have : Add Nat := inferInstance
  -- many other steps
  have : n + m = m + n := h1 -- error

This is treacherous, since the offending have can occur many lines before the error.

Example where a user was confused about this here.

Proposal
  • The tactic have x? : T := _ will emit a warning if T is a type (anything that is not always a proposition).
  • A new tactic have! which has the current behavior of have. (Optionally: have! emits a warning when the type is a proposition, and suggests the user to use have instead).
  • The warning for have suggests the user to switch to either let or have!.
  • We ensure that have' and haveI (in Std) have the same behavior (and add have'! and haveI!)
  • Term-mode have and let should probably adopt the same behavior

  • User Experience: This will decrease the number of mistakes from beginners, and will hardly inconvenience experienced users.

  • Beneficiaries: Mainly beginners, but everyone

  • Maintainability: Should have almost no influence on maintainability.

Community Feedback

Overwhelming support on Zulip. Other Zulip threads: 1 2 3

Impact

Add 👍 to issues you consider important. If others benefit from the changes in this proposal being added, please ask them to add 👍 to it.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

No files, tests, or entry points are named in the issue, so begin by locating the tactic and term-mode implementations for have, have', and haveI. Define the warning and new syntax behavior across the listed cases, then add coverage showing the warnings and suggested alternatives.

Written by the indexing model from the issue text.

Assessment

Domain
compilers
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.