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
