Infinite precision intermediate arithmetic: how much would break?

scottmcm:

In green-field there's a version of this that works great, actually. I don't think it'd be feasible to more Rust's default numerics to doing it, but for something new (or maybe a new type in Rust?) it actually works wonderfully.

For existing Rust code: Yes, it would break too many things (e.g. if someone relies on wrapping behavior with --release). But I don't think we need or necessarily want a new type for this. It would probably be better to add a block that lets you change the behavior of these operators, that way you can easily switch between them and not need to replace + with *_add everywhere.

Example:

// Keep the existing behavior (i.e. wrapping in --release, checked in debug builds)
a + b * c;

// A block that allows implicit type changes as long as there are provably no
// overflows and it behaves as it would with arbitrary-size integers
// (i.e. the behavior proposed in this thread)
bikeshed {a + b * c};

// Explicitly opt-into wrapping in both cases (both do the same thing)
a.wrapping_add(b.wrapping_mul(c));
wrapping {a + b * c};

// Saturating
a.saturating_add(b.saturating_mul(c));
saturating {a + b * c};

// Checked with result propagation
checked {a + b * c}.unwrap(); // checked block returns option
// Roughly equivalent to:
function foo(a: usize, b: usize, c: usize) -> Option<usize> {
    a.checked_add(b.checked_mul(c)?)
}
foo(a,b,c).unwrap()

Inspiration: unchecked in solidity which removes overflow checks.

With pattern types (might have been called something else) that'd be like your Int<MIN, MAX> but easier to use together with normal integer types. Implementing a separate type would probably be easier than arithmetic mode blocks + (internal) pattern types, but using the existing integer types makes it feel more natural and part of the language. [1]

Another advantage is that you could if that is desired (for new projects or after careful consideration of all arithmetic) set the default for an entire module/crate. To me being able to specify the behavior of a block of operations feels more useful and flexible for the future than completely separate types or not having AIR in the language entirely (+ it's convenient for things like wrapping behavior).

Those blocks might be possible to do with a macro, but the AIR part (named bikeshed above) probably isn't.

1. If I remember correctly there was also the proposal to replace/alias the primitives with Int<MIN,MAX> as an alternative to pattern types. ↩︎