Where possible, I prefer making the syntax opt-in, and explicitly so. For example, stealing OCaml's syntax:

let check_exp (g : Elliptic_curve_pt.t) (x : int) (y : int) = let xy = x * y in let open Elliptic_curve_pt.Num_syntax in (g ^ x) ^ y = g ^ xy

This lets you avoid making hard decisions about what can be added/multiplied/etc. at the language level -- can a list of numbers representing the coefficients of a polynomial be added? -- without jumping to the extreme of allowing anything implicitly. This also lets the typechecker catch more of your mistakes by having stricter types, and means you know exactly where to go to find out what the syntax is encoding.

I think, you could also write

    Elliptic_curve_pt.Num_syntax.( (g ^ x) ^ y = g ^ xy )

instead of let open Elliptic_curve_pt.Num_syntax in ...

> You probably shouldn’t be using += for your concatenation code

I agree. That's why D uses a separate operator for concatenation, ~=

That removes the temptation to overload +=.

What would be the definition of such "Number" class? How would it prevent any abuse?

A ring [0] might be too general, but I can't think of anything that isn't a ring that I'd want to call a "number" class. A field [1] is less general and might be a better fit. It probably depends whether you want a matrix to be able to be a "number," which I'd be inclined to do.

[0] https://en.wikipedia.org/wiki/Ring_(mathematics)

[1] https://en.wikipedia.org/wiki/Field_(mathematics)

The type systems underlying computer algebra systems like Sage, GAP, etc. are immensely more complex than this. Read the source of Sage (lots of python/cython) and the source of GAP (pure c; everything is basically a void *). Operator overloading is immensely helpful for entire classes of objects -- groups, rings, fields, categories, combinatorial objects... some of them are kinda number-like, but for example groups can support multiplication and division but not addition/subtraction (unless it's an abelian group and you'd rather represent it that way). I've been writing C for nearly 30 years, and GAP is a slog to read. Sage makes this stuff way easier.

In short... math isn't just arithmetic, isn't even arithmetic of complex tensors. Math is way bigger than most programmers seem to comprehend. I'm on the other side of the DK curve; I know that I've only scratched the surface despite a decade of dedicated study

Natural numbers don't form a ring, and integers don't form a field.

Good callout. What would you use if you had to restrict operator overloading to an appropriate “number” abstraction?

If we're actually requiring things be a ring, rather than approximating something that is a ring, that rules out floating point numbers (lack of associativity, at least).

As for definition, it already exists: https://docs.oracle.com/javase/8/docs/api/java/lang/Number.h...

As for abuse prevention: it would be impossible to use the common operators like +, -, +=, <<, >> and so on for anything that is not numbers, and therefore prevent C++ levels of overloading abuse.

But any class can inherit that Number, there is nothing enforcing that the subclass is particularly number-like. You can do just stuff like

    class MyString extends Number

and you get access to operator overloads. Only thing that makes this annoying is Javas lack of multiple inheritance, but that is pretty minor thing.

There is a level of stupid that is deniable, and a level that is not. MyString extends Number is going to lead more swiftly to words with your coworkers.