This feature produced counterintuitive behavior and confused users.
See discussion at #770.
As pointed out by @tydeu, it is not too much work to write `Id.run <|`
before the `do` when we want to use the `do` notation in pure code.
closes#770
closes#318
Like Lean 3, we are doing it only for theorems.
@Kha, we talked about doing it for definitions too, it sounded like a
good idea, and it would make the system's behavior more uniform, but
unfortunately it creates too many problems. There are so many trivial
cases where it breaks. Here are some examples.
1- Definitions that take multiple bundled structures
```
def foo (s1 : Group) (s2 : CommRing) ...
```
They are universe polymorphic, and the different structures must be in
the same universe, but we don't know it when we elaborate the header,
that is, we need to elaborate the body.
An extreme case is `PUnit` occurring in the header. It is universe
polymorphic, but we only lear the constraints on this universe after
we elaborate the body.
2- All files containing unification hints broke.
Again, there are universe constraints on the header that we only learn
after we elaborate the body.
3- Many `CoeSort` and `CoeFun` examples broke.
Example:
```
structure Group :=
(carrier : Type u) (mul : carrier → carrier → carrier) (one : carrier)
instance GroupToType : CoeSort Group (Type u) :=
CoeSort.mk (fun g => g.carrier)
```
We would have to write
```
instance GroupToType : CoeSort Group.{u} (Type u) :=
CoeSort.mk (fun g => g.carrier)
```
We would have to provide universe level parameters manually in this
kind of instance. I think it would be too annoying.
