Operator overloading, structs

[bearophile]

Don:

> Still, I wonder if D could simply do something like defining that for classes:
> if (x)  is always transformed into  if ( x!=0 )
> if (!x) is always transformed into  if ( x==0 )

Explicit is better than implicit. For example I'd like to have a set collection that is "false" when empty. In such situation I can write just the following method, it seems simpler and semantically cleaner than alternatives:

bool opBool() { return this.length != 0; }


>On second thoughts, y = x.toLong or y = to!(long)(x) is probably better. Casts are evil, implicit casts even more so.<

I don't know. Using esplicit casts/methods may be safer. 

So with your current changes to BigInt, in the following program to replace the int "i" with a BigInt:

void main() {
    int i = 1;
    if (i)
        i++;
    auto a = [10, 20, 30, 40];
    printf("%d\n", a[i]);
}

you need to change the code like this:

void main() {
    BigInt i = 1;
    if (i != 0)
        i++;
    auto a = [10, 20, 30, 40];
    printf("%d\n", to!(long)a[i]);
}

The toBool will help avoid the change in the second line.

I'd like to change programs as little as possible when I change the type of a variable from int to BigInt. This has also the big advantage that I can write templated algorithms that work with both ints and BigInts with as few "static if" as possible (to manage BigInts in a special way, for example adding that to!(long) ). That's why in such situation an implicit casting is handy.

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

Such almost-transparent replacement of ints with BigInts can be done also if BigInts are fast to perform operations with small integers (like with integers in range -1073741824 .. 1073741824).

I have done few easy benchmarks (that I can show you if you want) and I have seen that when a bigint contains only ~30 bits of data or less a BigInt is much slower than an int. Some speed difference is inevitable, but to help such replacement I think it can be good if BigInts gain speed optimizations for small such numbers. (And when you use BigInts that contain 5000+ bits such optimizazions don't slow down BigInts significantly).

Possible idea: you can test if the number needs less than 31 bits, if so, you can compute the operation using just a "long". If the result then can be stored back in about 31 bits, then you are done. This is slower than a simple operation among "ints" but it may be much faster than the same operations done with BigInts.

When numbers are so small the BigInt may also avoid all heap activity (Lisp languages do this using tags, they use a tagged pointer, that can be a small integer, avoiding any memory allocation when the number is small enough).

Bye,
bearophile