[GTALUG] overflow checking [was Re: A find alternative: fselect]

[D. Hugh Redelmeier]

| From: David Mason via talk <talk at gtalug.org>

| You can turn the checks on, but see this discussion about the default: https://github.com/rust-lang/rust/issues/47739

Thanks.  The issue isn't "resolved" so I guess that the default has
not been changed.

One comment pointed at this which I found fascinating:

<https://capnproto.org/news/2015-03-02-security-advisory-and-integer-overflow-protection.html>

Again, I found that being able to declare variables as being within a
range as being very powerful.  I admit that the edges get messy: just
as requiring arrays to have compile-time bounds is constraining,
tight compile-time bounds on integer types is sometimes overly
constraining.

Of course what we have in most languages is compile-time bounds, but
with the hope that they are generous.  And usually they are.

One could argue that if overflow is rare, we should be able to handle
it by falling over to bignums.  Unfortunately that adds overhead to
every operation -- perhaps JIT compiling techniques could fix that.

Maybe a single solution doesn't fit all cases.  But silently yielding
a wrong answer on overflow is just dangerous.  And defining the wrong
answer to be correct is not really better.

My intuition is that range declaration and checking might actually
might be more efficient that simple overflow checking.  The compiler
would have more actionable information to optimize out checks.  After
all, most functions are not "partial": the result is well-defined if
the parameters conform to their constraints.  It's sometimes hard to
express those constraints in the type system.