Catch integer arithmetic errors

[codec-abc]

In this issue I define arithmetic error as an computation that does not yield the same result that it would purely from a mathematical point of view (like underflow, overflow) or a computation that yield a result when one is not defined (division by 0). From an user point of view, these kind of errors are almost never done on purpose and will surely result in a program that doesn't have the desired behavior (at least locally). As such I would like that somehow integer arithmetic errors can be caught by Pony and "dealt" with.

As a reference I stumbled on this puffs project that can be a great source of insight. Among other thing the project tries to provide a solution to integer arithmetic overflows. Moreover the README compare itself to other languages (C, Rust, D and Swift) about how they approach the problem.

[jemc]

For whatever it's worth, I think underflow in particular actually ends up being used on purpose fairly often, but we can agree to disagree.

For overflow/underflow, have you seen the addc, subc, and mulc methods that pony integers already have?

[codec-abc]

Re-reading my first message, I realized that I worded my thought poorly. I am not against underflow/overflow/clamping/division by 0 per se. I just think these kind of behavior are not good default and it would be better if they are explicit in the code when someone want them to happen.

I didn't known about addc, subc and mulc. They are great because they clearly show that that any code using it has been written taking into account the possibility of overflow.

[SeanTAllen]

@jemc I think addc et al are rather hidden. I think at minimum that a FAQ entry, Pony pattern or highlighting in the tutorial is in order. Thoughts?

[codec-abc]

For sake of completeness, I think integer conversion - when choosing a new type that cannot hold all values of the previous- should be part of this issue too. For example converting a number whose value is 300 : U16 cannot be represented properly in a U8. While not strictly arithmetic operation, type conversion can lead to the same kind of bugs.

[jemc]

One more note that is more of a comment than a definitive answer to the overall question:

The puffs project you linked to seems to be leaning heavily on value-dependent typing, something which has been worked on extensively for Pony, but not yet actually been merged in.

[Arceliar]

I'm still very new to pony, so it's entirely possible that I'm just wrong, but I think I'd want to catch arithmetic errors about as often as not. I understand and agree with the arguments for why it probably shouldn't be the default, but I'd probably use it all the time if it was easy enough to do (or rather, I'd be more likely to use pony over another language if it could help me easily catch arithmetic errors when I need to).

From playing around with it just a little, directly using addc and friends feels a little tedious to me, mostly from the tuple return type. If I needed to write something with checked arithmetic today, then what I'd probably do is wrap addc/subc/mulc in partial functions. I'd do the same for division and floats (though I'm not sure exactly how to handle floats), and then use a the partial arithmetic functions in a try block in the cases where I want to make sure that there are no silent / unexpected errors.

I think defining partial wrapper functions is simple enough to do myself if I needed them, but I also wouldn't complain if the language had something like this built in. I guess you could even go a little crazy and define partial operators, so something like x +? y would be equivalent to x.addp(y)? (or whatever the functions would be called), but I don't know how well that would sit on the page.