Big integrals, opApply autoindex, safer integrals

[bearophile]

Recently we have discussed a lot about the balance of putting things inside the language or outside of it. It's a subtle balance and it's dynamic too, with time it can change (for example the removal of complex numbers from D2?). Surely it will need more discussions in the future too.

In the past I have discussed about the uses of multi-precision integral numbers. They can be put inside the std lib (std.bigint) or inside the compiler (many other languages, etc).

But there's another intermediate solution regarding those multi-precision numbers: keep them outside the language but allow the language to manage them with a transparent syntax. So even if the compiler doesn't know how to add two of such numbers (and you have to load such operations from a module), the syntax of the language allows you to write:

import bigints: Bigint;
...
Bigint x = 71_459_266_416_693_160_362_545_788_781_600;

Instead of:
BigInt x = "71459266416693160362545788781600";

This keeps the implementation of the operations outside the compiler, keeping it simpler and allowing different implementations, for example using bindings to the GNU multiprecision, and allows the user to manage such numbers in a transparent way, as (or almost as) they were built-in in the language.

(Such strategy of putting just "transparent" syntax support into the language, and keeping the implementation outside it, can be used in other situations too, for example for a possible set data structure, etc).

-----------------------

In my structs/classes that support iteration I may have a method like:
int opApply(int delegate(ref string) dg) {...}

But I may also often want to iterate on such objects with a progressive index too, so I have to duplicate all the code like this:

int opApply(int delegate(ref int, ref string) dg) {...}

I think it can be useful to invent some way for the compiler to create such second method by itself, (only when the programmer asks so).

(There are alternative ways to solve this problem, for example creating an iterable struct like xenumerate() similar to the Python enumerate(), or iterating the single-argument opApply() inside the two argument opApply(), but such solutions slow down the code).

-----------------------

The recent discussions about numbers with double meaning have to address bugs-waiting-to-happen like this too:

long n = 1_000_000 * 1_000_000;
Now n == -727379968

And several other silly things like the following ones:

uint n2 = -100;
now n2 == 4294967196

writefln(050); // ==> 40

Bye,
bearophile