I think we can have fast overflow checks (and probably faster inbound checks too), but even if we do not implement less precise exception throwing right away, I think we should allow it in the Julia specification (well there is none, standardized, though a few things have been defined, I recall though only regarding operator chaining).

Overflow checking was brought up, as potentially too costly, for the unlikely place of DateTime, hypothetically 8% slower, I explained here that with 8-times unrolling it could be brought down by that factor, to 1%:

#50930 (comment)

8% was likely way too conservatively pessimistic. If we assume the 2% slower of SaferIntegers.jl documentation, then it would be brought down to 0.25% overhead. I think by then it's in the noise and we should just allow overflow checking by default.

Note, what this is NOT, or not yet, proposing overflow checking by default.

@chriselrod Do you think this would work, or have any insight? I'm thinking as in the example there, assuming SaferIntegers.jl used, then you would have 8 places to potentially overflow, when you do a +, in your loop, and you could make all but the last redundant.

That assumes the compiler proofs they are all redundant (i.e. likely not possible if you have early exits from the loop, but that's probably ok, since not too common, or if done I think you could have an extra check outside of the loop).

Since we only really need to worry about speed in (unrolled) loops, and we could go further and optimze some check to go outside of loops, after, OR BEFORE? Would people be ok with exceptions being thrown prematurely?

In either case you lose the index of the loop (completely) when the exception happened. As opposed to if checks only done last in an unrolled loop, then you would have some calculation (or bounds check) for A[i] was thrown, but we can only limit i to [i - unroll, i], e.g. for one of 8 possible is (is unrolling ever done more than 8 times?).

We should have a debug more (I've also been thinking of that for other reasons) where you could run with exceptions precise, i.e. allow what's done for status quo.

[This idea would help for overflow checks for + and -, what needs to be optimized at a minimum. I do have other ideas for dealing with *, which this idea alone doesn't seems to help, except for small constant factors such as << 2.]