On 10/10/13 20:28, H. S. Teoh wrote:
I left some comments on these bugs. Basically, BigInt should not be
implicitly castable from const/immutable to unqual, because unlike the
built-in types, it's *not* a value type:
BigInt x = 123;
BigInt y = x; // creates an alias to x's data.
BigInt a = 2;
BigInt b = a;
b = 3;
writeln(a);
writeln(b);
... gives you:
2
3
So, even though there's an array hidden away inside std.BigInt, it still seems
to copy via value.
Of course, the way BigInt is implemented, any operation on it causes new
data to be created (essentially it behaves like a copy-on-write type),
so it's not as though you can directly modify immutable this way, but
it breaks the type system and opens up possible loopholes.
I guess that explains my result above .... ?
What you need to do is to use inout for functions that need to handle
both built-in ints and BigInts, e.g.:
inout(Num) abs(Num)(inout(Num) x) {
return (x >= 0) ? x : -x;
}
This *should* work (I think -- I didn't check :-P).
I did, and it results in issues with BigInt's opCmp. But that may say more
about BigInt's opCmp than about your solution.
Arguably, a *lot* of generic code involving numerical operations is
broken, because they assume built-in types' behaviour of being
implicitly convertible to/from immutable (due to being value types).
How would you suggest correcting that?
