Support overflow checks of arithmetic operations

[MaxGraey]

Most modern compilers like Rust and Swift support special set arithmetic operations which cause to exceptions when result is overflow or underflow.

• In Swift all integer operations checked by default but support special operations like &+, &- and &* for unchecked operations.

• Rust has much more clever approach. In Debug mode all operations overflow checked but in release all kind of operations are wrapped if not specify flags like -Z force-overflow-checks. In the same time Rust provide wide range builtin methods for handling overflow behaviour per operation like: a.wrapping_add(b) (allow overflow), a.saturating_add(b) (like clamp(res, i32::MIN, i32::MAX)), a.overflowing_add(b) (return (i32, bool) tuple) and a.checked_add(b) (return Option<i32>)

So I propose add similar feature for AssemblyScript in this way:

Unchecked (wrapped/overflowed) operations (default for now)

a + b
a - b
a * b
a / b
a % b
a++
--a
!a

Checked operations which produce unreachable exception in runtime during overflow:

a !+ b
a !- b
a !* b
a !/ b
a !% b
a!++
--a!
!a // <-- need figure out how handle this. Hmm, may be `!a!`?

Why !+, !* and etc?

First of all it has great semantic look ! which mean warning, exception and exclusion. Secondary symbol ! on TS after variables is legit and ignore during transpiling except case when a: i32 | null. When a define as optional type in my opinion we could write something like this a! !+ b which also legit.

Why this important?

This protect code from bugs. This especially important for smart contracts and history of Ethereum/EVM knows many examples when ignoring overflow costs a lot of money.

WDYT?

[jtenner]

I don't think typescript tooling will like these operators. It will cause people to have to deal with errors in their problems tab.

Maybe we can have a checked(expression) macro?

[jtenner]

Another suggestion might be a Checked<Number> type.

[MaxGraey]

Yes checked may be an option. But produce more verbosity.
Checked<i32> is bad idea because this cause to a lot of problems when we try to mix checked type with unchecked. Should we cast all unchecked types to unchecked? Implicitly or explicitly? In both cases this produce more verbosity and makes refactoring difficulty. All languages resolve this in operation level not type level

[jtenner]

Right. I was thinking the same thing. How about a grouped postfix !. Like this: (a + b)! ?

I think that's valid typescript too.

[MaxGraey]

yes, this is valid as well.

btw one more cons to checked. We already have unchecked for fast bound uncheck access to array's buffer so mixed a[i] = unchecked(checked(b + c)) will confuse

[jtenner]

Using "!" for non null assertions and checked expressions is gonna be confusing too. I'm just at a loss for good options at this point. We are very limited by the typescript compiler.

[dcodeIO]

Makes sense to me. Would prefer checked and unchecked contexts for this similar to C#, and maybe rename our current unchecked to something else, maybe unsafe?

Once there are closures, something like this could also work

checked(() => {
  ...
  ...
  ...
});

by tagging the entire inner function context.

[MaxGraey]

Yeah. C# uses checked(a + b) for that stuff. In my opinion much better than a.checked_add(b) because much easier for refactoring but still verbosity. Ideally is something like in Swift &+, &* ... but this not valid for typescript unfortunately.

Also good suggestion from @jtenner:

(a + b)!, (a / b)!

[MaxGraey]

Another funny (magic?) variant =)

a +~~ b
a -~~ b
a *~~ b
a /~~ b
a !~~ b
~~a++
--~~a
!~~a 

[dcodeIO]

(a + b)!, (a / b)!

Not sure about reusing ! for something different than its semantic meaning. That was the reason for not merging non-null assertions initially, because I didn't know what we'd like to do with it instead, but then came to the conclusion that doing it the same way TS does it makes the most sense. Might be that there are ways to make it work in multiple ways, but I still think that developer experience would suffer from having to deal with one operator with multiple semantics.

[jtenner]

How about comments like @ts-ignore?

EDIT: This means that operation validation would be on the statement level instead of on the expression level.

// @as-validate(: Reason)
// @as-overflow-checks(: Reason)

[jtenner]

Another suggestion might be block level checks like this:

// choose an intuitive block name here
as_validate: {
  // this block generates overflow checks
}

Also note that reused block names are valid javascript, so there shouldn't be any issues with this approach.

[dcodeIO]

The label idea looks nice, but might of course conflict with labels at some point. Hmm...