Arithmethic overflow should not raise an exception

Community spends hours arguing against an idea

Community member creates shard for said idea, gets a round of applause, “awesome work, man!”

Pick one.

Now, while this shard is good, the initializer parameter seems redundant. If it’s Saturating(Int32), it’s inferred we know the max value, we don’t need to pass in Int32::MAX. Likewise, for example, if it’s Saturating(UInt32), we know the max value as well.

Would be better and more bonus points if we could simply do Saturating.new(0_u32), or whatever inline type we specified.

This means that in any case when the wrapped type would overflow or underflow,

There underlies the problem. Intrinsically in crystal and how it’s infused with mathematics, there should be no underflows or overflows, when there is a MAX and MIN value paired with a respective Int type.
See image:
image

This reigns more true because of the Int32 (enum member variables).

When a developer is creating an instance var, let’s say property gold = 0. The developer knows the max value. If that developer wants to warn a user about reaching the max gold, that onus is on them. The onus is absolutely NOT on the developer to litter a codebase with redundant if statements. This goes against the entire point of having a beautiful syntax.

Other languages suffer from this as well (just tested it in dlang)