Catch integer arithmetic errors about rfcs HOT 6 OPEN

@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?

from rfcs.

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?

from rfcs.

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.

from rfcs.

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.

from rfcs.

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.

from rfcs.

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.

from rfcs.