WIP/RFC: Add explicitly wrapping versions of integer arithmetic

[Keno]

This adds operators +%, -%, *%, which are equivalent to the non-% versions, but indicate an explicit semantic expectation that twos completement wrapping behavior is expected and correct. As discussed at JuliaCon 2014 and every year since, users have often requested a way to opt into explicit overflow checking of arithmetic, whether for debugging or because they have regulatory or procedural requirements that expect to be able to do this. Having explicit operators for overflowing semantics allows use cases that depend on overflow behavior for correct functioning to explicitly opt-out of any such checking.

I want to explicitly emphasize that there are no plans to change the default behavior of arithmetic in Julia, neither by introducing error checking nor by making it undefined behavior (as in C). The general consensus here is that while overflow checking can be useful, and would be a fine default, even if hardware supported it efficiently (which it doesn't), the performance costs of performing the check (through inhibition of other optimization) is too high. In our experience it also tends to be relatively harmless, even if it can be a very rude awakeing to users coming from Python or other languages with big-default integers.

The idea here is simply to give users another tool in their arsenal for checking correctness. Think sanitizers, not language change. This PR includes a macro @Base.Experimental.make_all_arithmetic_checked, that will define overrides to make arithmetic checked, but does not include any mechanism (e.g. #50239) to make this fast.

What is included in this PR:

• Flisp parser changes to parse the new operators
• Definitions of the new operators
• Some basic replacements in base to give a flavor for using the new operator and make sure it works

Still to be done:

• [] Parser changes in JuliaSyntax
• [] Correct parsing for +% by itself, which currently parses as +(%)

The places to change in base were found by using the above-mentioned macro and running the test suite. I did not work through the tests exhaustively. We have many tests that explicitly expect overflow and many others that we should go through on a case by case basis. The idea here is merely to give an idea of the kind of changes that may be required if overflow checking is enabled. I think they can broadly be classed into:

• Crypto and hashing code that explicitly want modular arithmetic
• Bit twidelling code for arithmetic tricks (though many of these, particularly in Ryu, could probably be replaced with better abstractions).
• UInt8 range checks written by Stefan
• Misc

That said, I'm not sure I'll have the time to actually finish this, so I'd be grateful if someone else wanted to take this over to push it through.

[c42f]

In order to decide what to do about JuliaLang/JuliaSyntax.jl#408, I think we need to have the syntax debate here in JuliaLang/julia @jakobnissen

Looking through the files, I can see various cases where +% is mixed up with other operators in a fairly natural way which motivates having special syntax for this.

I'm not sure it deserves its own syntax though, and I'd like to discuss other possibilities:

A macro

We could have a macro (eg, @modular) which rewrites operators to user modular versions. Similar in spirit to @fastmath, but indicating a difference in operator semantics rather than an unsafe performance annotation.

• Pros: no special syntax, cleaner if all arithmetic in an expression is modular, can support modular assignment operators, some analogy to the mathematical notation a + b == c (mod m) where the mod is done separately.
• Cons: less clean than special syntax if there's a mixture of modular and non-modular

Code example from PR where it's cleaner:

    s4::UInt64 = s0 +% (3 *% s1) +% (5 *% s2) +% (7 *% s3), # internal splitmix state
# vs
    s4::UInt64 = @modular s0 + (3 * s1) + (5 * s2) + (7 * s3), # internal splitmix state

Using unicode subscripts

For example +ₘ (the subscript m being for "modular", for example)

• Pros: clean for mixed expressions, other pros of special syntax
• Cons: Can't do modular op-assign operators like x +=ₘ y

    s4::UInt64 = s0 +% (3 *% s1) +% (5 *% s2) +% (7 *% s3), # internal splitmix state
# vs
    s4::UInt64 = s0 +ₘ (3 *ₘ s1) +ₘ (5 *ₘ s2) +ₘ (7 *ₘ s3), # internal splitmix state

Plain old function names

• Pros: Plain ascii names, no additional syntax
• Cons: Less visual analogy between modular vs non-modular expressions. Can't do op-assign operators.

Special syntax

• Pros: Only ascii - easy to type. Works well for mixed modular and non-modular expressions
• Cons: Yet more special syntax. Compatibility issues as usual; eg can't be covered neatly by Compat.jl

Summary

Considering the above, I'm somewhat favoring the idea of a @modular macro which rewrites non-modular arithmetic operators into modular ones (with + calling some Base.add_mod or whatever) . It can do all the same things as special syntax, and arguably has some cute analogy to the mathematical notation.

(What if, as a future extension @modular m (x + y) could do modular arithmetic in base m?)