@digama0 After this commit, your example will also produce a
non-destructive update.
```lean
structure test :=
(data1 : array nat 3)
(data2 : array nat 3)
(sz: nat)
def test.write (s : test) (i : fin 3) (v : nat) :=
{s with data1 := s^.data1^.write i v, data2 := s^.data2^.write i v}
set_option trace.array.update true
(fin.of_nat 1) 10 in
(a^.data1^.read (fin.of_nat 1), a^.data2^.read (fin.of_nat 2)) -- destructive write
```
See discussion at #1438https://github.com/leanprover/lean/pull/1438#discussion_r105007325
@digama0 With this commit, the original `array_list.write` will also
perform a destructive update when the reference counter for `l` is 1.
```lean def write {α} (l : array_list α) : fin l^.length → α → array_list α :=
λ ⟨n, h⟩ v, { l with data := l^.data^.write ⟨n, l^.lt_capacity h⟩ h v }
```
Motivation: if the explicit part matches (what the user sees), then the implicit part must morally match too.
If it doesn't because of reducibility setting, the behavior is usually counterintuitive.
Summary:
- A field value was being elaborated more than once when there is
another field whose default value depends on it.
The new test `structure_default_value_issue.lean` exposes the problem.
- Better error message and localization at field type mismatches.
When there is field type mismatch, the error message contains the
field name, and the error is reported at the field position instead of
`{`.
- We add support for auto_param at structure instances `{...}`
See #1422
@johoelzl I'm using `abstract` tactic because instances are
automatically marked as [reducible], and they will be unfolded when
solving unification constraints. This cannot be avoided since we need to
solve unification constraints such as
int.has_add =?= comm_ring.to_has_add int.comm_ring
The `abstract tac` tactic creates an auxiliary lemma to store the proof
generated by `tac`. If we use `print int.comm_ring` we can see that
the definition is much smaller. The proofs are irrelevant. So, this has
no drawbacks, and gives us a good performance boost.
Remark: The kernel was already using Sort. So, the limitation was
artificial. Moreover, it may seem unnecessary to have quotients of
proofs in a proof irrelevant system, but this is useful for proving
a more general funext lemma. This more general version is needed in
the new tested contributed by @digama0.
