overflow in arithmetic with <strike>Optionals</strike> errors

[RogierBrussee]

Zig has both intrinsics like

fn @addWithOverflow(T : type, a:T, b:T, res: *T) bool

and optional types. While being explicit about the types of the summands seems useful, in a language that has optionals it seems natural to write

fn @addWithOverflow(T: type a:T, b:T) ?T

Better still, with the precedent of operators like +% it seems that operators +?, -? , *? and /? would fit in so one can write

if( a+? b) |res|{
//no overflow
} else {
// overflow
}

One documentation advantage is that a + b can be defined as a + b == (a +? b).? including the undefined behaviour.

[LemonBoy]

Check out std.math

[RogierBrussee]

Ok so std.math defines

fn add(T: type a:T, b:T) error{Overflow}!T

then the proposal is to make that function the @-intrinsic (with or without "withOverflow" in the name), drop the existing @addWithOverflow and define operators +!, -! , *! and /! (where the latter failing with error{DivisionByZero}) so the syntax would be

const res = try a +! b ;

meaning

const res = try @add(a, b);

Luckily a +! b does not mean a + (!b) already, because ! is not defined on u and i integers :-).

At least for documentation purposes e.g. "ordinary" addition is defined s.t.

a + b == try a +! b orelse unreachable;

making +! /@add the more primitive operation (at least conceptually).

Note that (a +! b) *! c is a syntax error (if you are careful be careful and have just one potential failure per line),
but ( a + b) *! c is OK.

Indeed errors are probably nicer than optionals. Zig makes handling failure smooth, and overflow is always an option, so I think that making it as easy as possible to deal with overflow is good.