Skip to content

Commit

Permalink
inst implicit -> implicit
Browse files Browse the repository at this point in the history
  • Loading branch information
kmill committed Sep 27, 2024
1 parent d89f201 commit c4f5ae9
Showing 1 changed file with 4 additions and 5 deletions.
9 changes: 4 additions & 5 deletions src/Lean/Elab/App.lean
Original file line number Diff line number Diff line change
Expand Up @@ -654,10 +654,10 @@ mutual
if (← anyNamedArgDependsOnCurrent) then
/-
See the note in processExplicitArg about `anyNamedArgDependsOnCurrent`.
For consistency, instance implicit arguments should remain instance implicit if a named
argument depends on them.
For consistency, instance implicit arguments should always become implicit if a named argument depends on them.
If we do not do this check here, then the `nextArgHole?` branch being before `processExplicitArg`
would result in counterintuitive behavior. For example, in the following the `_` is optional.
would result in counterintuitive behavior.
For example, without this block of code, in the following the `_` is optional.
When it is omitted, `processExplicitArg` sees that `h` depends on the `Decidable` instance
so makes the `Decidable` instance argument become implicit.
When it is `_`, the `nextArgHole?` branch allows it to be present.
Expand All @@ -672,8 +672,7 @@ mutual
example : p := @foo (h := h) inferInstance
```
-/
discard <| mkInstMVar (← getArgExpectedType)
main
addImplicitArg argName
else if let some stx ← nextArgHole? then
/- Recall that if '@' has been used, and the argument is '_', then we still use type class resolution -/
let ty ← getArgExpectedType
Expand Down

0 comments on commit c4f5ae9

Please sign in to comment.