Investigate feasibility of overflow checks

[chriseth]

Me might want to add forced overflow checks for 0.7.0 leading to an invalid opcode. We should check if it is possible to implement common contracts with require checks such that the invalid opcode is not reachable.

[chriseth]

What we also have to consider: Do we want checks for truncation during type conversion? Is unchecked { ... } too much of a burden for these? Does it happen a lot?

[leonardoalt]

I think it would be interesting to force checks there as well. If someone wants to safely convert to a smaller type, they'd need to properly adjust the value first.

[chriseth]

It seems we currently do not check overflow for explicit type conversion when compiling via yul.

[chriseth]

Community feedback call: #9054

[chriseth]

Outcome of community call:

• slight preference towards checks by default, to be disabled via unchecked { ... }.
• as a compromise between invalid() and revert() we could use a special error signature in revert.
• ** can only be used inside unchecked { ... } unless the types and constants do not allow any overflow
• overflow checks on type conversions probably still need some investigation.

[axic]

@chriseth can we close this after #9465 ?